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Introduction 


The VAX Technical Summary introduces the characteristic features 
and capabilities of the VAX system to computer analysts and system 
programmers. Application programmers, system managers, and 
operators can also use this summary to become familiar with the 
components, services, and operations of the VAX system. 


Power and performance, a wealth of languages and pro- 
gram development tools, information management facili- 
ties, distributed processing and networking capabilities, 
and a broad base of support services make the VAX family 
of 32-bit computer systems the standard for the 1980s. 


The VAX architecture is the cornerstone upon which the 
VAX family has been built. This architecture — a collection 
of common attributes shared by all the family members — 
ensures software compatibility across VAX systems. Com- 
mon attributes include the instruction set, the addressing 
modes, and data types, among others. 


Attributes not included in the architecture, such as proces- 
sor internal bus structure, implementation-specific privi- 
leged registers, execution speeds, etc., allow VAX 
engineers with the flexibility to use different technologies 
to create systems at different price and performance lev- 
els. 


This flexibility in design has brought about the introduction 
of two new systems to the VAX family. So our first VAX sys- 
tem, the high-performance VAX-11/780, and our 
midrange VAX-11/750 have been joined by the VAX- 
11/782 Attached Processor, an asymmetrical multipro- 
cessing system designed for large computational jobs and 
the VAX-11/730, a compact system that brings VAX proc- 
essing power to the departmental level. 


The same VAX/VMS virtual memory operating system 
runs on all of the VAX processors. It provides priority sche- 
duling, management, security, and accounting controls. 
There is a single set of commands for timesharing, real- 
time, batch, and interactive jobs. Because of the common 
architecture and the single operating system, programs 
can move from one system to another without reprogram- 
ming, recompiling, or relinking. 


In addition, by using our broad offering of programming 
languages, different program modules can be written in 
different languages, the system services can be called in 
any language, and any language can be called by any 
other language. 


Common architecture and compatibility are ‘naturals’ for 
distributed processing considerations as well as for esta- 
blishing and/or adding to a network. Because we offer a 
range of processors, appropriately sized systems can be 
located where their power is needed. They can share infor- 
mation with other systems; they can be used as a central 
base for storing or processing information from many sys- 
tems; they can serve as stand-alone units; or they can act 
as network nodes. 


Networking capabilities allow a VAX system to link with 
other VAX systems, with PDP-11 systems, and with DEC- 
systems through DIGITAL‘s own DECnet software. The In- 
ternet software permits VAX systems to exchange infor- 
mation with other vendors’ computer systems. And 
through Packetnet System Interface software VAX sys- 
tems can communicate over the Public Packet-Switched 
Networks that are being used in many countries through- 
out the world today. 


Whatever your computing needs, there is a VAX system 
with the right combination of power and performance to 
help you do your job. This summary presents in technical 
detail the features and capabilities of the VAX systems. 
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In particular, this edition introduces several significant sys- 

tem enhancements: 

© The newest members of the VAX family: the VAX-11/730 
and the VAX-11/782. 


® Version 3.0 of the VAX/VMS operating system. 


® The addition of new language implementations, includ- 
ing VAX-11 FORTRAN and VAX-11 COBOL. | 


* Acompletely new language: VAX-11 C. 

© Information management facilities using VAX-11 DBMS, 
VAX-11 DATATRIEVE, the VAX-11 Common Data Dic- 
tionary, and the Record Management Services. 


© New peripherals. 


© Added support services, including Customer Runnable 
Diagnostics for the VAX-11/730. 


The VAX Technical Summary contains useful information 
for the application programmer, the system manager, and 
the computer operator, yet the level of technical detail 
makes the book particularly appropriate for the system 
programmer and/or computer system analyst. 


You can read the VAX Technical Summary in either a se- 
lective or sequential manner. An abstract prefaces each 
section of the summary. Many of the system’s concepts 
and features are repeated throughout the text in various 
contexts. 

The System section presents a comprehensive overview of 
VAX system features that are described in detail through- 
out the remainder of the summary. It also serves as an in- 
troduction for those familiar with computer industry termi- 
nology, identifies VAX characteristics, and introduces the 
system features. 


The Users section contains a description of the command 
language and its features. It also introduces many of the 
aspects of the system that support applications 
programming, system management, and operator control. 


The VAX Processors and Operating System sections pro- 
vide an indepth discussion of the system’s characteristics 
and capabilities. The concepts developed in these two 
sections are closely related. For example, the respective 
discussions of memory management, I/O processing, and 
the compatibility-mode environment oughtto beread 
together in order to acquire a full appreciation for the sys- 
tem‘s design. 

One of the most important advantages of the VAX system 
is that programmers do not have to know assembly lan- 
guage to use the system effectively. Both hardware and 
software contain many features that promote efficient and 
productive high-level language programming. High-level 
language programmers should find the Users, Languages, 
Information Management Facilities, and Data Communica- 
tion Facilities sections, of particular interest. The begin- 
ning of the Operating System section is also helpful be- 
cause it introduces some of the VAX software terminology 
and concepts. 


Also the Program Development section will be of interest 
to high-level language programmers. It describes the 
basics of creating, editing, debugging, and executing a 
program written in any of the VAX high level languages. 
The section also contains an introduction to some of the 
advanced features of the command language. 


You can obtain even more literature describing VAX fea- 
tures, capabilities and applications by contacting a 
DIGITAL sales office near you. 
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The VAX system provides the performance, reliability, and programming fea- 
tures often found only in much larger systems. The VAX family of processors 
have a 32-bit architecture based on the PDP-11 family of 16-bit minicomputers. 
While using addressing modes and stack structures similar to those of the 
PDP-11, VAX provides 32-bit addressing for a four Gbyte program address 
space, and 32-bit arithmetic and data paths for processing speed and accu- 
racy. 


The processor’s variable-length instruction set and its variety of data types — 
including decimal and character-string — promote high bit efficiency. The 
processor hardware and instruction set specifically implement many high-level 
language constructs and operating-system functions. 


VAX is a multiuser system for both program development and application-sys- 
tem execution. It is a priority-scheduled, event-driven system; the assigned pri- 
ority and activities of a process in the system determine the level of service 
needed. Realtime processes receive service according to their priority and 
ability to execute, while the system manages CPU time and memory residency 
allocation for normal executing processes. 


VAX is a highly reliable system. Builtin protection mechanisms in both the hard- 
ware and software ensure data integrity and system availability. Online diag- 
nostics and error detecting and logging verify system integrity. Many hardware 
and software features provide rapid diagnosis and automatic recovery, should 
power, hardware, or software fail. 


The system is both flexible and extendible. The virtual memory operating sys- 
tem enables the programmer to write large programs that can execute in both 
small and large memory configurations, and this can be done without the 
programmer having to define overlays or later modify the program to take ad- 
vantage of additional memory. The command language enables users to mod- 
ify or extend their command repertoire easily; it also allows applications to pre- 
sent their own command interface to users. 


INTRODUCTION 

VAX is a high-performance multiprogramming computer 
system that is ideally suited for a wide variety of applica- 
tions, including realtime, batch, timesharing, commercial, 
data processing, and program development. The system 
combines a 32-bit architecture, efficient memory manage- 
ment, and a virtual memory operating system, to provide 
essentially unlimited program address space. 


The processor’s instruction set includes floating-point, 
packed-decimal arithmetic, and character-string instruc- 
tions. Many of the instructions are direct counterparts for 
high-level language statements. The software system sup- 
ports programming languages that take advantage of 
these instructions to produce extremely efficient code. 


The VAX/VMS virtual memory operating system provides 
a multiuser, multilanguage programming environment on 
the VAX hardware. The floating-point instructions, efficient 
scheduler, and optional VAX-11 FORTRAN language are 
ideal for realtime and scientific computational environ- 
ments. The optional VAX-11 COBOL language, informa- 
tion management services, and large-capacity peripherals 
make the system equally suited to commercial applica- 
tions. VAX/VMS supports many other optional high-level 
languages that are suitable for other applications. The 
system management facilities, command language, and 
program development tools provide the resources needed 
for efficient program application development and execu- 
tion. Spooling and extensive job control capabilities sup- 
port batch processing. 


The processor executes variable-length instructions in na- 
tive mode and nonprivileged PDP-11 instructions in 
compatibility mode. Native mode includes the PDP-11 
data types. It uses addressing modes and instructions 
similar to those of the PDP-11. The software supports 
compatible languages and file and record formats. 


COMPONENTS 

The major components of a VAX system are: 

e Processor — includes the basic central processing unit 
implementing the VAX architecture. The specific im- 
plementations of the VAX processors — the VAX- 
11/782, VAX-11/780, VAX-11/750, and VAX-11/730 — 
will be treated in greater detail in Section 4, The VAX 
Processors. 

e Peripherals — includes a range of small- and large-ca- 
pacity disk drives, magnetic-tape systems, hardcopy 
and video terminals, lineprinters, cardreaders, and real- 
time I/O devices. 


e Operating System — includes a virtual memory man- 
ager, swapper, system services, device drivers, file sys- 
tem, record management services, command language, 
and operator’s and system manager's tools. 


e Languages — includes the native-mode languages, 
VAX-11 MACRO and, optionally, VAX-11 FORTRAN, 
VAX-11 COBOL, VAX-11 C, VAX-11 BASIC, VAX-11 
PL/I, VAX-11 PASCAL, VAX-11 BLISS-32, and VAX-11 
CORAL 66. Also supported in compatibility mode are 
PDP-11 FORTRAN IV/VAX-to-RSX, and MACRO-11. 
Development tools for both native- and compatibility- 
mode programs include editors, linkers, librarians, and 
debuggers. 
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e Utilities and Program Development Tools — includes 
several editors, linker, librarian, and debugger. 


e Information Management Facilities — comprises a file 
system, volume structuring, and protection; Record 
Management Services (RMS), for record management 
and indexed and sequential file support; DATATRIEVE, 
tor data inquiry, update, and application writing; DBMS, 
a database management system; CDD, a common data 
dictionary; and FMS, a forms management system. 


e Data Communication Facilities — includes the DECnet- 
VAX network software, Internet protocol emulators, and 
Packetnets. 


Processor 

Architecturally, a VAX processor provides 32-bit address- 
ing, sixteen 32-bit general registers, and 32 interrupt pri- 
ority levels. The instruction set operates on integer, float- 
ing-point, character-strings and packed-decimal strings, 
and bit fields. The instruction set supports nine addressing 
modes. 


The processor includes an efficient memory cache, result- 
ing in greatly reduced memory access time. (Memory 
cache is not available in the VAX-11/730 processor). 


Error-Correcting Code (ECC) MOS memory is connected 
to the memory interconnect via a memory controller. Each 
memory controller includes a request buffer that substan- 
tially increases overall system throughput and eliminates 
the need for interleaving in most applications. 


The processor uses two standard clocks — a programm- 
able realtime clock used by the operating system and by 
diagnostics and a time-of-year clock used for system op- 
erations. The time-of-year clock includes battery backup 
for automatic system restart operations. 


The console is the operator’s interface to the central 
processor. Via the console terminal, the operator can exe- 
cute diagnostics, install new software, examine and depo- 
sit data in memory locations or processor registers, halt 
the processor, step through instruction streams, and boot 
the operating system. 


Virtual Memory Operating System 

VAX/VMS is a multiuser, multifunction virtual memory op- 
erating system that supports multiple languages, an easy- 
to-use interactive command interface, and program devel- 
opment tools. The VAX/VMS operating system is designed 
for many applications, including scientific and realtime, 
computational, data processing, transaction processing, 
and batch. 


The operating system performs process-oriented paging 
that allows execution of programs that can be larger than 
the physical memory allocated to them. Paging is handled 
automatically by the system. This frees the user from any 
need to structure the program. In the VAX/VMS operating 
system, a process pages only against itself; thus, individ- 
ual processes cannot significantly degrade the perform- 
ance of other processes. 


The memory-management facilities provided by the oper- 
ating system can be controlled by the user. Any program 
can prevent pages from being paged out of its working set. 


With sufficient privilege, it can prevent the entire working 
set from being swapped out, to optimize program 
performance for realtime or interactive environments. 
Sharing and protection are provided for individual 512- 
byte pages. The processor’s memory management in- 
cludes four hierarchical processor access modes that are 
used by the operating system to provide read/write page 
protection between user software and system software. 
The access modes, from most- to least-privileged, are ker- 
nel, executive, supervisor, and user. 


VAX/VMS schedules CPU time and memory residency on 
a preemptive priority basis. Thus, realtime processes do 
not have to compete with lower-priority processes for 
scheduling services. Scheduling rotates among processes 
of the same priority. The scheduler adjusts the priorities of 
processes assigned to one of the low 16 priorities, to im- 
prove responsiveness and to overlap I/O and computa- 
tion. Realtime processes can be placed in one of the top 16 
scheduling priorities, in which case the scheduler does not 
alter their priority. Their priorities can be altered by the 
system manager or an appropriately privileged user. 


Interprocess communication is provided through shared 
files and shared address space, event flags, lock-manage- 
ment services, and mailboxes that are record-oriented 
virtual devices. 


VAX/VMS provides system management facilities. A sys- 
tem manager and a system operator are given the tools 
necessary to control the system configuration and the op- 
erations of system users, for maximum efficiency. 


The VAX/VMS command language is easy to learn and 
use and is suitable for both the interactive and batch envi- 
ronments. Extensive batch facilities under VAX/VMS in- 
clude job control, multistream spooled input and output, 
operator control, conditional command branching, and 
accounting. 


Command procedures are supported by the command 
languages as easy methods of executing strings of fre- 
quently used sequences of commands or of creating new 
commands from the existing command set. Command 
procedures accept parameters and can include extensive 
control flow. 


VAX/VMS provides a program development capability 
that includes editors, language processors, and a sym- 
bolic debugger. The VAX-11 FORTRAN, VAX-11 COBOL, 
VAX-11 C, VAX-11 BASIC, VAX-11 PL/I, VAX-11 PASCAL, 
VAX-11 BLISS-32, VAX-11 CORAL 66, and VAX-11 MA- 
CRO language processors produce native code. The PDP- 
11 FORTRAN IV/VAX to RSX, and MACRO-11 language 
processors produce compatibility-mode code. 


The VAX/VMS operating system provides a file and record 
management facility that allows the user to create, access, 
and maintain data files and records within files, with full 
protection. The record management services handle se- 
quential, relative, and multikey indexed file organizations; 
sequential and random record access; and fixed- and vari- 
able-length records. 


The VAX/VMS operating system supports the Files-11 On- 
Disk Structure Level 2 (ODS-2); ODS-2 provides the facili- 
ties for file creation, extension, and deletion with owner- 
specified protections and multilevel directories. Ondisk 
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Structure Level 2 is upwardly compatible with Level 1 (the 
file system currently available under the PDP-11 IAS and 
RSX-11 operating systems). Both native- and compatibil- 
ity-mode programs can access both Level 1 and Level 2 
volume structures. 


DECnet-VAX networking capabilities are available for 
point-to-point and multipoint interprocess communica- 
tion, file access, and file transfer; and a downline com- 
mand file and RSX-11S system loading. The Network 
Command Terminal facility allows users on one system to 
log into another VAX system on the network. The Mail fa- 
cility allows electronic mail to be addressed to users on 
any VAX node in the network. 


Peripherals 

Medium-capacity disks, unit record devices, terminals, the 
interprocessor communications links, and user-specific 
devices are UNIBUS peripherals. The UNIBUS adaptor(s) 
provide(s) the hardware pathways for data and control in- 
formation to move between the UNIBUS and the memory 
interconnect. 


High-performance MASSBUS mass storage peripherals 
are connected to the memory interconnect via a buffered 
MASSBUS adaptor. The MASSBUS adaptors provide the 
hardware pathways for data and control information to 
move rapidly between a MASSBUS peripheral controller 
and the memory interconnect. 


PERFORMANCE 

Many features of VAX ensure that the system provides 
realtime, computational, and transaction-processing ap- 
plications with the appropriate processing speed and 
throughput. 


The processor provides 64-bit, 32-bit, 16-bit, and 8-bit 
arithmetic; instruction prefetch; and an address translation 
buffer. 


An optional high-performance floating-point accelerator 
(FPA) can be added to the VAX-11/782, VAX-11/780, VAX- 
11/750, and VAX-11/730 systems. The FPA is an indepen- 
dent processor that executes in parallel with the base 
CPU. The FPA takes advantage of the CPU’s instruction 
buffer to prefetch instructions and memory cache to ac- 
cess main memory. Once the CPU has the required data, 
the FPA overrides the normal execution flow of the stan- 
dard floating-point microcode and forces use of its own 
code. Then, while the FPA is executing, the CPU can be 
performing other operations in parallel. The FPA executes 
standard floating-point instructions with substantial per- 
formance improvement. This execution is architecturally 
transparent to the programmer. In addition, the FPA en- 
hances the performance of a number of additional instruc- 
tions including: 

® extended multiply and integerize (EMOD) 


® polynomial evaluation (POLY), (F_floating and 
D_floating formats for both instructions) 


® all floating-to-integer and integer-to-floating conver- 
sions 


© 8- and 16-bit integer multiply (MULB and MULW) 
® extended multiply (EMUL) 
© 32-bit integer multiply (MULL) 


The EMOD instruction is used for fast and accurate range 
reduction of mathematical-function arguments. The POLY 
instruction is used extensively in the evaluation of such 
mathematical functions as sine and cosine (the VAX/VMS 
mathematics library makes use of the POLY instruction to 
significantly reduce the execution time of its subroutines). 
The MULL instruction is often used in matrix manipulation 
subscript calculations. 


The VAX processor architecture is specifically designed to 
support high-level language programming. Because the 
instruction set is extremely bit-efficient, compilation of 
high-level-language user programs is also very efficient. 
Among the features of the processor that serve to reduce 
program size and increase execution speed are the: 

® variable-length instruction format. 


® floating-point, packed-decimal, and character-string 
data types. 


® indexed, short-displacement, and program-counter re- 
lative addressing modes. 


® small, constant short literals. 


Furthermore, many instructions correspond directly to 

high-level-language constructs: 

® the Add Compare and Branch instruction for DO and 
FOR loop control. 


® the Case instruction for computed GO TO statements. 


® the three-operand arithmetic instructions (for state- 
ments such as “A = B+C’”). 


® the Index instruction for computing index values, includ- 
ing subscript range checking. 


® the Edit instruction for output formatting. 


Much of the processor architecture also ensures that the 

operating system incurs minimal overhead for realtime 

multiprogramming. For example, the operating system 

uses: 

® the context-switching instructions and queue instruc- 
tions to schedule processes. 


® the asynchronous system trap (AST) delivery mecha- 
nism, to speed returns from system service calls. 


Careful design, coding, and performance measurement 
ensure that the flow within the system is as rapid as possi- 
ble. 


Very large compute-intensive programs can take advan- 
tage of the VAX-11/782 Attached Processor — a tight cou- 
pled asymmetrical multiprocessing system that offers a 
60- to 80-percent performance improvement over a single 
VAX-11/780. 


The compute-intensive programs would typically execute 
almost entirely in the attached processor, leaving the pri- 
mary processor free for !/O. 


RELIABILITY 

Built-in reliability features for both hardware and software 
provide data integrity, increased uptime, and fast system 
recovery from power, hardware, or software failures. Sev- 
eral of the VAX reliability features are discussed in the fol- 
lowing paragraphs. 
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Data Integrity 

VAX provides memory access protection both between 
and within processes. Each process has its own indepen- 
dent virtual address space that can be mapped to private 
pages or shared pages. A process cannot access the pri- 
vate pages of any other process. The VAX/VMS operating 
system uses the four processor access modes to read 
and/or write protect individual pages within a process. 
Protection of shared pages of memory, files, and interpro- 
cess communication facilities, such as mailboxes and 
event flags, is based on file ownership and application- 
group identification. 


The VAX/VMS file system detects bad blocks dynamically 
and prevents reuse once the files to which they are allo- 
cated have been deleted. 


Integral fault detection hardware includes: 

® memory error-correcting code that detects all double- 
bit errors and corrects all single-bit errors. 

® disk error-correcting code that detects all errors up to 
11 bits and corrects errors in a single burst of 11 bits. 


® extensive parity checking. 

® peripheral write/verify checking that checks all input 
and output disk and tape operations and ensures data 
reliability. 

® track offset retry hardware that enables the operating 
system to recover from many disk-transfer errors. 


System Availability 

The VAX/VMS operating system allows the VAX system to 
continue running, even if some of its hardware compo- 
nents may have failed. The system automatically deter- 
mines the presence of peripherals on the processor at 
bootstrap time. If the usual system device is unavailable, 
the system can be bootstrapped from any disk. If memory 
units are defective, memory is configured so that defective 
modules are not referenced. Software spooling allows out- 
put to be generated, even if the normal output devices are 
not available. Also, devices can be added online. 


The system operator can perform software maintenance 
activities without bringing the system down for stand-alone 
use. The operator can perform disk backup for both full- 
volume backup/restore and single file backup/restore, 
concurrent with normal activities. 


The VAX/VMS operating system supports online peripher- 
als diagnostics. VAX/VMS performs online error logging 
of CPU errors, memory errors, peripheral errors, and soft- 
ware failures. The operator or field service engineer can 
examine and analyze the error log file while the system is 
in operation. 


System Recovery 

Automatic system restart facilities bring up the system 
without operator intervention after a system failure caused 
by a power interruption, a machine-check hardware mal- 
function, or a fatal software error. The VAX/VMS operating 
system automatically performs machine checks and inter- 
nal software consistency checks during system operation. 
If the checks fail, VAX/VMS performs a system dump and 
reboots the system (if the operator has set the system for 
autorestart). 


Memory battery backup can be used to preserve the con- 
tents of memory during a power outage. A special memory 
configuration register indicates to the recovery software 
whether data in memory has been lost. Following a power 
failure, the recovery software restarts all possible I/O that 
has been in progress before the failure occurred. Pro- 
grams can use the VAX/VMS powerfail asynchronous sys- 
tem trap facility to initiate user-specific powerfail recovery 
processing. If memory battery backup is used, the time-of- 
year clock allows the recovery software to calculate 
elapsed time of the outage. 


VAX remote diagnosis allows DIGITAL to run diagnostics, 
examine memory locations, and diagnose hard- 
ware/software problems from a remote diagnosis center. 
The engineer who goes to the site is prepared in advance 
to correct any problems that may have occurred. 


FLEXIBILITY 
VAX is a system that is easy to use because it is both flexi- 


ble and easy to extend. Several of the ways in which VAX 
provides the user with flexible operating and programming 
environments are introduced below. 


Flexibility in the Operating Environment 

Virtual memory gives the user the ability to write and exe- 
cute arbitrarily large programs without concern for 
addressing limitations. The paging and swapping algo- 
rithms allow more programs to execute than the available 
physical memory would allow, had all programs been re- 
quired to be totally resident. 


Both paging and swapping are transparent to the user 
and, therefore, allow the system to be extended without re- 
programming. The system’s physical memory configura- 
tion can change without requiring program redesign or re- 
linking. Programmers never have to structure their 
programs, although they can — at their option — to 
achieve maximum efficiency and performance for a given 
program. They can control working set size, lock pages in 
the working set or memory, and lock an entire working set 
in memory. In addition, the system manager can control 
the amount of time a process is guaranteed memory re- 
sidency, once it has been swapped in. 


The VAX/VMS scheduler recognizes 32 scheduling priori- 
ties. A program can modify its priority during execution. 
Realtime processes execute at one of the high 16 priority 
levels, and normal processes (including system 
processes) execute at one of the low 16 priority levels. The 
scheduler can temporarily increase the priority of anormal 
process to increase its response to I/O events or system 
events, but it can never lower the priority of realtime proc- 
ess. 


Batch and printer output processing are completely flexi- 
ble. The operator controls the number of batch jobs that 
can run concurrently. The operator defines the number of 
spooler queues. There can be multiple print queues — a 
generic queue for jobs that can be output on any printer 
and several queues for jobs that are designated for a spe- 
cific printer. 

Batch jobs can be submitted to batch streams from the 
interactive environment, using a terminal command; from 
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another batch job; or by any program using a system call. 
Submitted batch jobs are queued, and a time can be spec- 
ified after which a batch job should be executed. 


Flexibility in Programming Interfaces 

The I/O programming facilities can be as device-indepen- 
dent or device-specific as desired. The record manage- 
ment services support high-level programming languages 
by providing transparent record access. They also enable 
the programmer to request specific record management 
services or system services, to control file allocation, re- 
cord blocking, or record accessing directly. Programmers 
can also use the system services to access file-structured 
devices or non-file-structured devices, if they wish, to use 
their own record-processing or volume-structuring tech- 
niques. 


Access to network facilities is device-independent, but a 
user can exert control over operations to obtain error re- 
ports or notification of broken connections (interrupt mes- 
sages, inbound connections). System access protection 
applies to all network access. 


Programmer Productivity 
In addition to the system’s reliability and performance fea- 


tures described above, VAX offers many tools that aid pro- 

grammer productivity. 

e Interactive editors with CAI startup — VAX/VMS sup- 
ports several interactive and batch text editors, 
including SOS, SLP, and the DIGITAL standard editor, 
EDT. The system features a computer-aided instruction 
course to introduce the user to the power and flexibility 
of EDT. 


e Interactive Symbolic Debugger — The interactive sym- 
bolic debugger provides a fast and efficient method by 
which the user can trace program errors. The debugger 
offers the user such features as; support of various na- 
tive languages, support of many data types, and interac- 
tive symbolic operation. 


e FMS interactive screen format generation — The Forms 
Management System (FMS) contains an interactive 
editor that allows the application programmer to create 
and/or modify screen formats. 


e DATATRIEVE — DATATRIEVE software provides fast 
and convenient access to data within a file or files. This 
query and report-writing system provides the user with 
either video or hardcopy output. 


e DBMS — Database Management System allows users to 
access complex, interrelated data, and ensures data in- 
tegrity. It also permits the management of databases for 
multiple users. 

HELP facility—The HELP facility provides the user with 


online instructions pertaining to selected system opera- 
tions. 


Extending the System 
The VAX/VMS command language can be extended with 


user-defined commands through the use of command 
procedures. A command procedure is a set of commands, 
data, or other command procedures processed in se- 
quence. The user can invoke command procedures with a 
single command that can include parameters for the pro- 
cedure — such as file names or values for symbols. Com- 


mand procedures can execute programs, transfer control 
within the command procedure conditionally or 
unconditionally, request input from the user, and manipu- 
late numeric and string symbols. 


VAX/VMS uses a standard procedure call interface sup- 
ported by the processor’s call instructions. The calling 
program and called procedure can be written in different 
languages. This contributes to the writing of error-free, 
modular, and maintainable software that can be shared by 
many programs. The standard procedure call interface is 
particularly useful to systems programmers who want to 
add their own sharable libraries and library procedures to 
the VAX/VMS Common Runtime Procedure Library. 


PDP-11 Compatibility 

Users who already know the PDP-11 will find the native 
VAX-11 instruction set and programming characteristics 
easy to learn when developing new applications for the 
VAX system. The PDP-11 and the VAX systems have al- 
most identical FORTRAN, BASIC, and COBOL languages. 
Users who have programmezd in any of these languages on 
the PDP-11 will need to spend very little time learning the 
VAX system. 
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VAX offers many PDP-11 compatibility features: 
e the VAX processor can execute a subset of PDP-11 16- 
bit instructions in compatibility mode. 


the VAX/VMS operating system provides functionally 
equivalent system services for many RSX-11M executive 
directives. 


the VAX/VMS high-level language compilers accept 
source languages that are upwardly compatible with the 
same PDP-11 compilers. 


the VAX/VMS file system can read and write disk vol- 

umes and magnetic tapes written under RSX-11 and IAS 

operating systems. 

e the VAX/VMS record management services provide re- 
cord-processing methods that are upwardly compatible 
with RMS-11 record management services. 

e the VAX/VMS operating system provides an RSX-11 
MCR command language interpreter. 

e the DECnet-VAX package supports RSX-11S system im- 

age downline loading. 


These features make VAX an ideal host system to PDP-11 
systems in a distributed processing environment. 


BLANK 


_ 
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The VAX system is designed to execute many different kinds of jobs concur- 
rently. Jobs consist of one or more processes, each of which can be executing 
a program image that interacts with online users, controls peripheral equip- 
ment, and communicates with other jobs in the same system or in remote com- 
puter systems. Jobs include: 

e Customer-written interactive, batch, and realtime applications. 

@ Interactive and batch program development jobs. 


e System management and control jobs. 


Typically, VAX users interact with application or system jobs via an online 

terminal or benefit from batch or realtime jobs. To aid in the development of 

interactive, batch, and realtime applications and manage and control system 

resources, VAX enables: 

e The application programmer to write, compile, and test programs interac- 
tively or in batch mode, taking advantage of source code, object code, and 
program image libraries. 


e The system programmer to design application systems that require a high 
degree of job and process interaction, data sharing, response time, and sys- 
tem and device independence. 


e The system manager to authorize users, limit resource usage, and grant or 
restrict privileges individually. 

e The system operator to monitor operations, service user requests, and con- 
trol batch production. 


Users can directly control the operation of VAX through the operating system’s 
command language. In general, the command language is used by 
programmers to develop application software, by operators to monitor the sys- 
tem, and by system managers to assign user privileges. 


Application programmers can also employ the command language to execute 
their application programs explicitly. The command language can be easily ex- 
tended to provide custom-tailored commands defined by the user. Customer- 
written application programs can provide their own command interfaces for 
people using the system. Transaction processing applications can require sev- 
eral terminals to be slave terminals, meaning that they are tied to particular ap- 
plication programs that handle requests entered by the user. 


The system manager can assign access user names and passwords to users 
who log on the system at a command terminal and can determine their privi- 
leges for obtaining services and limits for using resources. Users who access 
the system through an application terminal interface have the resources and 
privileges granted to the application programs run on their behalf. An applica- 
tion program itself determines who can request its services. 


THE APPLICATION PROGRAMMER 

The application programmer has four basic tools for re- 
questing system services: 

© Command interpreter 

e Programming languages 

© Programmed file and record management services 

e Programmed system services 


The application programmer gains access to the system 
through the command interpreter. The command interpre- 
ter enables the programmer to create, compile, and exe- 
cute programs written in any of several programming lan- 
guages. The record management services are available 
through any programming language to provide device-in- 
dependent data processing. The system services, al- 
though primarily of interest to systems programmers, are 
also available to the application programmer for request- 
ing special services of the operating system. 


Command Language 
The command interpreter is interactive, comprehensive, 
easy to use, and extremely flexible. It enables the user to 


log onto the system, manipulate files, develop and test 
programs, and obtain system information. Furthermore, it 
enables users to extend or redefine their command reper- 
toire as well as write command procedures easily. The 
command language includes: 


e A set of English commands that provide the basic com- 
mand repertoire. 


e A set of control characters that provide special functions 
such as erase command line, interrupt the program cur- 
rently executing, etc.. 


e A set of special operators and commands that can be 
used to automate command streams and extend the 
command repertoire. 


Table 3-1 lists the basic set of English commands ac- 
cepted by the command interpreter. The command inter- 
preter is easy to use because its commands can be abbre- 
viated, because it prompts for necessary arguments, and 
because it assumes standard or user-selected default 
values for command parameters and qualifiers. 


Table 3-1 
DCL Command Language Summary 


GENERAL SESSION INFORMATION 
AND CONTROL 


LOGIN The user initiates an interactive session with the system by typing CTRL/C, CTRL/Y or 
by pressing the carriage return on a terminal not currently in use. The system then 
prompts for username and password, and validates them. 


HELP Displays information to assist the user in selecting the proper command qualifiers. 


SHOW Displays any of the following information: current day, date, and time; current default 
device and directory name; status of devices in the system; logical device name as- 
signments; current characteristics and status of specified mag tape device; name, 
number, and status of local network node and lists available remote nodes; default 
characteristics of system printer; status of current process; current file protection to 
be applied to all new files created during terminal session or batch job; current status 
of entries in printer/batch job queues; current disk quota; current VAX-11 RMS de- 
fault multiblock and multibuffer counts; status of currently executing image in proc- 
ess; current value of a local or global symbol; displays a list of processes and status 
information in system; current characteristics of a specified terminal; logical name 
translations; display of working set quota and limit assigned to current process. 


SET Defines default translation mode for cards read into system card reader; controls 


ASSIGN 


DEFINE 
DEASSIGN 


whether command interpreter receives control when CTRL/Y is pressed; changes the 
user’s default device name or directory name; defines default characteristics for spe- 
cific magtape device; determines whether command interpreter performs error 
checking following execution of commands in command procedures; changes execu- 
tion characteristics of currently executing process; invokes the VAX-11 Command 
Definition Utility to add commands; changes a file’s protection; changes the charac- 
terisitic of a file; changes current status or attributes of a file queued for printing or for 
batch job execution; defines default values for multiblock and multibuffer counts used 
by VAX-11 RMS; changes characteristics of a specified terminal; controls whether or 
not command lines in command procedures are displayed at terminal or printed in 
batch job log; redefines default working set size for the current process. 


Assigns a logical name to a given character string (equivalence name) and stores the 
the pair of names in a process, group, or system logical name table. Generally used to 
create a logical name for a device. 


Creates a logical name equivalence. (Same as ASSIGN except for syntax.) 


Breaks the correspondence between a logical name and its equivalence name (see 
ASSIGN and ALLOCATE), or deletes a symbol (see DEFINE). 
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MCR 


PHONE 


MAIL 


LOGOUT 
REQUEST 


Table 3-1 
(con’t) 
DCL Command Language Summary 


Signifies that the given command or following command lines are to be interpreted by 
the RSX-11 command interpreter. 


Invokes the VAX/VMS PHONE utility that allows users on a system to talk to one 
another or to any user on another VAX system connected by DECnet-VAX. 


invokes the MAIL utility that allows users to send, receive, file, forward, and reply to 
messages. 


Terminates an interactive session and releases all resources allocated to the user. 


Displays a message at a system operator’s terminal and optionally requests a reply. 


BATCH AND COMMAND PROCEDURE 


SPECIFIC CONTROL* 
SUBMIT 


$PASSWORD 


$JOB 


SINQUIRE 


$GOTO 
SON 


SIF 


$EOD 
$EXIT 
$SEOJ 


DECK 


Places a given batch command file or command procedure in a batch queue for proc- 
essing. 


Specifies the password associated with the user name specified on a JOB card fora 
batch job. 


Indicates the beginning of a batch command file and provides job control information 
(such as time limit). 


Requests interactive assignment of a value to a symbol and assigns the symbola 
name. 


Transfers flow of control to a given labeled line. 


Transfers flow of control to a given labeled line if an error of a given severity or greater 
is encountered at any time during command procedure processing. 


Transfers flow of control to a given labeled line if the result of a logical comparison of 
symbolic values is true. 


Signifies the end of data in the input stream following a $DATA command. 
Terminates the command procedure. 


Marks the end of a batch job submitted through the system card reader. EOJ per- 
forms the same functions as the LOGOUT command. 


Marks the beginning of an input stream for a command or program. 


“Command names preceded by a $ are meaningful only in a batch command file or command procedure. All other 
commands listed in this table can either be issued interactively or used in a batch command file or command pro- 


cedure. 


VOLUME AND DEVICE RESOURCE CONTROL 


MOUNT 


INITIALIZE 


DISMOUNT 


ALLOCATE 


DEALLOCATE 
FILE MANIPULATION 
DIRECTORY 


CREATE 


EDIT 
DELETE 


DELETE/ 
ENTRY 


DELETE/ 
SYMBOL 


Requests the operator to make a volume available to the user and optionally associ- 
ates a logical name with the volume or volume set. 


Writes a directory file and other volume structuring information on a disk or magnetic 
tape volume to prepare it for use. 


Requests the operator to break the logical association of this device with the user’s 
job. 


Obtains exclusive ownership of device and enables the user to assign a logical name 
to the device. 


Releases allocated devices. 


Reports information (size, protection, ownership, creation time, etc.) on a given file or 
set of files. 


Creates a new file from data subsequently entered in the input stream (user at 
terminal or batch stream). Creates a directory file on a volume. 


Opens a text file and accepts commands to insert, delete or modify data in the file. 
Deletes one or more files from a mass storage disk volume. 


Deletes one or more entries from a printer or batch job queue. 


Deletes one or more symbol definition from a local symbol table or from the global 
symbol table. 


PURGE 


RENAME 
COPY 
APPEND 


DIFFERENCES 
SORT 


OPEN 
CLOSE 


READ 


WRITE 
PRINT 


TYPE 


DUMP 


UNLOCK 
ANALYZE 


Deletes all but the latest version of a given file or files, optionally keeping the latest two 
or more versions. 


Changes the name of one or more existing files. 
Copies the contents of a file or files, creating another file or files. 


Concatenates the contents of sequential files to a given output file, or creates a new 
output file from the concatenated contents of given sequential files. 


Compares two files and reports the differences between the two. 


Creates a file by rearranging the records in a given file based on the contents of key 
fields within the records. 


Opens a file for reading or writing at the command level. 


Closes a file that was opened for input or output with the open command and deas- 
signs the logical name specified when the file was opened. 


Reads a single record from a specified input file and equates the record to a specified 
symbol name. 


Writes a record to a specified output file. 


Sends the contents of a given file or files to a spooled output device such as a line 
printer. 


Displays the contents of a given file or files on the device identified by the logical name 
SYSS$OUTPUT: (default generally the user’s terminal). 


Produces a printed listing of the contents of a file, ignoring any print formatting char- 
acters that may appear in the records. 


Permits access to a file that was improperly closed. 


Provides a description of the records comprising an object file or object module li- 
brary; provides a description of the contents of an image file or sharable image file; 
invokes an RMS utility to inspect and analyze the internal structure of an RMS file; 
invokes the System Dump Analyzer to examine a running system or to examine a 
specified dump file; invokes the VERIFY utility to check readability and validity of 
Files-11 structure disk volumes. 


PROGRAM DEVELOPMENT AND 


EXECUTION CONTROL 


LIBRARY 


LINK 
RUN 


DEBUG 


EXAMINE 
DEPOSIT 
CONTINUE 
STOP 

SUBMIT 
SYNCHRONIZE 


WAIT 
CANCEL 


Creates, deletes, or maintains libraries of object modules, sharable images, or macro 
source modules. 


Links modules to produce images. 


Executes a program image in the current process context, or creates a detached 
process and executes a program image in that process context. 


Starts interactive debugging session after interrupting program image execution by 
typing a Control C or Control Y. 


Displays the contents of a location in virtual memory. 

Replaces the contents of a location in virtual memory with the given data. 
Resumes execution of a program interrupted by typing a Control C or Control Y. 
Terminates the program currently interrupted by a Control C or Control Y. 
Enters a command procedure in the batch job queue. 


Places the process executing a command procedure in a wait state until a specified 
batch job completes execution. 


Places the current process in a wait state until a specified period of time has elapsed. 


Cancels scheduled wakeup requests for a specified process. This includes wakeups 
scheduled with the run command and with the schedule wakeup (SSCHDWKkK) system 
service. 


3-3 


A command line normally consists of a command verb fol- 
lowed by one or more parameters that identify the object 
of the operation (a file, for example) or qualify how the op- 
eration is to be performed. If the interactive user enters an 
incomplete command, the command interpreter prompts 
for any necessary parameters. For example, the COPY 
command, which creates a copy of an existing file, accepts 
a total of two file specifications: one for the file to be 
created and one for the file to be copied. The file specifica- 
tions identify the exact location and name of the files. The 
COPY command can be entered in any of several ways: 


$ copy 
$ FROM: filename-1 
$ TO: filename-2 


$ copy filename-1 
$ TO: filename-2 


$ copy filename-1 filename-2 


The command interpreter displays the dollar sign to 
prompt for a command and the dollar sign underscore to 
prompt for a missing parameter. 


Command Procedures 

To eliminate the need for typing frequently repeated se- 
quences of commands, users can create command pro- 
cedures. A command procedure is a file containing com- 
plete command lines (including the $ prompt character). 
The user can request the command interpreter to read and 
process the command lines in a command procedure file 
just as if they were being typed successively at the 
terminal. To execute a command procedure, the user sim- 
ply precedes the name of the command procedure file 
with an “at” sign (@). For example: 


$ @procedure-file 


Figure 3-1 is a simple example of how a user might create, 
interactively, a new command called EXECUTE. The user 
has previously written a VAX-11 PASCAL program named 
AVE and now wishes to compile, link, and execute this 
program. To the user, EXECUTE appears to be a com- 
mand like any other command in the DCL command re- 
pertoire. The first step is to create the command pro- 
cedure file EXECUTE.COM. Following this, the user enters 
the PASCAL, LINK, and RUN DCL commands as input to 
the command file. 


The blue dollar signs in Figure 3-1 represent DCL system 
prompts; the remainder of the text is user supplied. 


$ CREATE EXECUTE.COM 
$ PASCAL AVE 

$ LINK AVE 

$ RUN AVE 

4Z (CONTROL Z) 

> 


Figure 3-1 


A Simple Command Procedure 
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To execute the command procedure file, EXECUTE.COM, 
the user can type: 


$ @EXECUTE 


or the user can create a symbol to execute the command 
file. The user may equate a unique series of letters to the 
command procedure file. For instance: 


$ EXE := @EXECUTE 


To execute the command procedure file, EXECUTE.COM, 
the user need only type the symbol EXE: 


$ EXE 


The user coujd just as easily have created a symbol called 
GO to execute the command procedure file 
EXECUTE.COM. In this instance: 


$ GO:=@EXECUTE 


To execute the command file, EXECUTE.COM, the user 
can enter GO in response to the DCL prompt ($): 


$ GO 


In addition to executing command procedures at a termi- 
nal, an interactive user can also submit batch jobs. Batch 
jobs execute under control of the system operator and 
leave the user’s terminal free to continue interactive or 
command procedure processing. A batch job can be sub- 
mitted as a deck of cards or as a batch command file. A 
batch command file is identical to a command procedure 
file, except that a batch command file submitted as a deck 
of cards begins with a $JOB card that provides job control 
information. 


However, DCL is more than just a string of commands ca- 
pable of standing alone; it possesses true high-level pro- 
gramming language statements such as GOTO, IF, etc., 
and accepts a series of up to eight user-defined parame- 
ters “P1” through “P8”. DCL can be used to completely de- 
fine and control a user environment tailored to a specific 
application. 


The power and flexibility of command procedures and the 
DCL command language will be treated in greater detail in 
the Program Development and Support Facilities section. 


RUN Command 

The RUN command includes several qualifiers (DELAY, 
INTERVAL, and SCHEDULE) which are of particular im- 
portance to the realtime programmer. 


Specifying any of the above qualifiers places a process in 
hibernation, a wait state in which the process can be reac- 
tivated only when a particular time value occurs. The time 
value can be specified in delta time (/DELAY qualifier), in 
absolute time (/SCHEDULE qualifier) or at recurrent inter- 
vals (JINTERVAL qualifier). When the image completes 
execution, the process returns to a state of hibernation. 


Programming Languages 

The system includes the VAX-11 MACRO assembler for 
programming the machine using its native instruction set. 
A wide variety of language processors is optionally avail- 
able to high-level language programmers: VAX-11 FOR- 
TRAN, VAX-11 COBOL, VAX-11 BASIC, VAX-11 C, VAX- 
11 PL/I, VAX-11 PASCAL, VAX-11 CORAL 66, and VAX-11 
BLISS-32. In addition, VAX/VMS supports optional lan- 
guage compilers that execute in compatibility mode. 


These include PDP-11 FORTRAN IV/VAX to RSX and MA- 
CRO-11. These language processors, introduced below, 
are described fully in the Languages section. 


The VAX-11 FORTRAN language processor conforms at 
the full level to the American National Standard Institute 
FORTRAN specification X3.9-1978 (commonly referred to 
as FORTRAN-77). The compiler is upward compatible with 
the PDP-11 FORTRAN IV and PDP-11 FORTRAN-77 lan- 
guages. Further, it provides optional switch-selectable 
support for programs conforming to the previous ANSI 
standard. Thus, programs written for older compilers both 
on PDP-11 systems and on other vendors equipment can 
be easily transported to VAX-11 systems. 


The VAX-11 FORTRAN compiler produces sharable, 
highly optimized VAX-11 native object code. The compiler 
takes advantage of the system’s large virtual address 
space while utilizing the floating-point and character- 
string instructions. FORTRAN I/O processing is supported 
by the record management services (VAX-11 RMS). VAX- 
11 FORTRAN object modules can be linked with assem- 
bler-produced object modules and the system’s runtime li- 
brary, which is common to all native mode programs, to 
provide standard library functions. The VAX-11 FORTRAN 
language processor offers the programmer such features 
as: 


® Full ANSI-77 FORTRAN language support. 


® Access to ISAM files as well as relative and sequential 
files. 


® Access to the VAX/VMS system services and the run- 
time library procedures. 

® FORTRAN program can call external routines written in 
other VAX-supported high-level languages. 


® The compiler itself is sharable. 


The VAX-11 COBOL language processor produces highly 
efficient sharable native-mode code that utilizes the 
system’s packed-decimal and character-string instruction 
set and extended call facility. The VAX-11 COBOL lan- 
guage is based on the American National Standard Insti- 
tute Programming Language COBOL, X3.23-1974, the in- 
dustrywide standard for COBOL. Most features planned 
for the next COBOL standard, based on the specifications 
in the Draft Proposed Revised X3.23 American Standard 
Programming Language COBOL, are also included. The 
VAX-11 COBOL language processor offers the program- 
mer such features as: 
® The ability to manipulate data strings via the INSPECT 
verb. 
® Performing sorting and merging operations at the CO- 
BOL source-language level. 


® Complete file organization capability including sequen- 
tial, relative, and indexed I/O. 


® Structured programming facilities including EVALUATE 
and PERFORM statements, and scope delimiters. 


® Support for block-structured programming. 

© Support for the full range of data types, including 
packed-decimal and floating-point. 

® COBOL programs can call external routines written in 
COBOL or other VAX-supported high-level languages. 
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® Capability of writing sharable code for use by other na- 
tive-mode high-level languages 


© Accepts source programs coded in either ANSI stan- 
dard format or the shorter, easy-to-read DIGITAL termi- 
nal format. 


© Supports the DML interface to DBMS. 
® Supports the Report Writer module. 


VAX-11 BASIC is a native-mode, sharable language- 
processing system producing sharable VAX native object 
code. The language compiler utilizes VAX floating-point 
and character-string instructions while supporting a fast 
RUN command and immediate mode execution that 
makes it well-suited for interactive use. VAX-11 BASIC is a 
superset of PDP-11 BASIC-PLUS-2, offering the VAX user 
major enhancements such as: 

® Access to VAX-11 RMS file and record processing. 


® Long variable names (up to 31 alphanumeric charac- 
ters). 


® Dynamic string handling. 

® CALL statement providing interface to common lan- 
guage environment. 

® Sharable and reentrant code. 


VAX-11 C is a general purpose programming language 
featuring modern control and data structures and a rich 
variety of operators for economy of expression. It is a com- 
plete implementation of the C Language developed at Bell 
Laboratories, as described in The C Programming Lan- 
guage, by Kernigan and Ritchie, and includes recent ex- 
tentions. 


VAX-11 C offers the C programmer several advantages, 
including generation of optimized, sharable, position-in- 
dependent native VAX code; fast compilation speeds; plus 
the ease and flexibility of development that goes along 
with using a language integrated within the VAX/VMS en- 
vironment. 


C features include: 

® Modern control constructs for efficient structured pro- 
grams. 

® Arich variety of simple and concise operators. 

© User-defined, or “enumerated” (ENUM) data types. 

© An extensive library of runtime support routines, includ- 
ing standard I/O, math and string functions, and access 
to the VAX-11 Common Runtime Library. 

® Runtime support to aid UNIX ™ to VAX/VMS migration 
including emulation of many UNIX-specific routines. 

® VAX-11 Symbolic Debugger support. 

® Extensive global and local optimization of generated 
code for reduced code size and increased execution 
speed. 

® Compiler-generated listings with several options. 


VAX-11 PL/I is an extended implementation of the pro- 
posed ANSI X3.74, American National Standard PL/I Gen- 
eral Purpose Subset to full PL/I (ANSI X3.53-1976). VAX- 
11 PL/I extensions include some full language features 
and VAX/VMS system-specific extensions. 


PL/I is a versatile language that is suited to commercial, 
scientific, and systems-programming applications. Some 
of the features of VAX-11 PL/I include: 

Block-structured language. 

Fuil support for all VAX-11 hardware data types. 
Powerful I/O capabilities, including ISAM support. 

User control of storage allocation. 

Condition handling. 


Standard VAX-11 CALL interface, including access to 
VAX/VMS System Services and the runtime library. 


e Fast native-mode optimizing compiler. 
e Sharable position-independent code. 


VAX-11 PASCAL, a reentrant native-mode compiler, is an 

extended implementation of the PASCAL language as de- 

fined in the PASCAL User Manual and Report (Jensen and 

Wirth, 1974). Particularly suited to instructional use, PAS- 

CAL is gaining increasing popularity as a general purpose 

language. Major features of the VAX-11 PASCAL language 

include: 

e Block structuring via the BEGIN...END compound state- 
ment, to allow easy logic flow. 

e Data structuring, including the ability to declare and use 
pointers, records, files and arrays. 


e Predefined procedures and functions to deal with I/O 
handling and data manipulation. 


VAX-11 PASCAL takes advantage of the VAX hardware 
floating-point and character-string instructions, as well as 
the virtual memory capabilities of the VAX/VMS operating 
system. Many of the features common to other native lan- 
guages are available through VAX-11 PASCAL including: 

e Separate compilation of modules. 


e Standard CALL interface to routines written in other lan- 
guages. 
e Access to VAX/VMS system services. 


The VAX-11 CORAL 66 compiler executes in compatibility 
mode and generates native-mode object code under 
VAX/VMS. The CORAL language, derived from JOVIAL 
and ALGOL-60 in 1966, is the standard language pre- 
scribed by the British government for military realtime ap- 
plications and systems implementation. VAX-11 CORAL 
66 is essentially a high-level block-structured language 
whose compiler offers the user many features including: 

e Several numeric types (byte, long and double). 

e Generation of reentrant code at the procedure level. 

e Code optimization. 

e English text error messages. 


e INCLUDE keyword to incorporate CORAL 66 source 
code from user-defined files. 


VAX-11 BLISS-32 is a high-level systems implementation 
language for VAX-11 that runs in native mode under 
VAX/VMS. The BLISS language is specifically designed 
for building language compilers, realtime processors, utili- 
ties, and operating-system software. BLISS contains many 
of the features of high-level languages (e.g., DO loops, IF- 
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THEN-ELSE statements, automatic stack, and mecha- 
nisms for defining and calling routines), but it also pro- 
vides the flexibility and access to hardware that one would 
expect from an assembly language. VAX-11 BLISS-32 can 
be used as an alternative to assembly-language coding in 
all except the most machine-dependent systems- 
programming applications. The VAX-11 BLISS-32 lan- 
guage processor offers the programmer such features as: 

e Program execution on architecturally different machines 

with little or no modification. 


e Construction of complex expressions in which several 
different kinds of operations can be performed in a sin- 
gle program statement. 


e Exploitation of high level language constructs. 


PDP-11 FORTRAN IV/VAX to RSX is an extended FOR- 
TRAN IV processor based on ANSI FORTRAN X3.9-1966. 
It supports mixed-mode arithmetic, extended I/O facilities 
for data formatting, error-condition transfer statements, 
bit manipulation, library usage, and several debugging fa- 
cilities. The FORTRAN IV compiler and its runtime system 
execute in the compatibility-mode environment. 


MACRO-11, the PDP-11 assembly language, is included in 
the compatibility-mode environment. Programs written in 
MACRO-11 can be assembled to produce relocatable ob- 
ject modules and optional assembly listings. 


Record Management Services 

The record management services (RMS) are a collection 
of procedures that extend the programming languages by 
providing general purpose file- and record-handling capa- 
bilities. Programmers using RMS include in their 
programs statements that read, write, find, delete, and up- 
date records within files. Records can be of fixed or vari- 
able length. 


RMS enables the programmer to choose the file organiza- 
tion and record access method appropriate for the data 
processing application. The file organizations and record 
access methods are independent of the language in which 
they are programmed, although some languages support 
file organizations and access methods not provided in oth- 
ers. Every programming language uses RMS to process 
files organized to provide sequential, random, or multi- 
keyed indexed record accessing. 


For further information on RMS and the system’s data 
management techniques, refer to the section on Informa- 
tion Management Facilities. 


THE SYSTEM PROGRAMMER 

The system programmer can use this system to design 
and build application systems for multiprogramming envi- 
ronments that require fast response and a high degree of 
job interaction and data sharing. 


Job and Process Siructure 

The user program environment consists of a job structure 
that can contain many processes. A process is the sche- 
dulable entity capable of performing computations in par- 
allel with other processes. It consists of an address space 
and an execution state that define the context in which a 
program image executes. An executing program is 


associated with at least one process, but it can be associ- 
ated with several processes. 


A multiple-process job structure allows one job to execute 
more than one program image at the same time. One 
process can wait for an event (such as I/O completion) to 
occur while another process continues its computations. 
The processes can communicate in several ways. They 
can coordinate their execution synchronously, using event 
flags, or asynchronously, using software-simulated inter- 
rupts. They can send messages back and forth using 
virtual record-oriented devices called “mailboxes” and 
can share code and data on disk and in memory. Also, the 
lock-management services provide a mechanism for syn- 
chronizing access to common resources by cooperating 
processes. 


Jobs can be grouped into application subsystems that 
share code and data that'sprotected from other applica- 
tions. The processes within jobs in the same group can 
coordinate their activities using group interprocess com- 
munication facilities such as mailboxes and event flags, as 
well as those facilities local to the job. They can access 
files and data in memory that are protected from other 
groups in the system. 


Multiprogramming Environment 

The system supports multiprogrammed applications that 
require high performance by providing: 

e Event-driven priority scheduling. 

e Rapid process context switching. 

e Minimum system service call overhead. 

e Processor access-mode memory protection. 

e Memory management control. 


The system schedules processes for execution based on 
the occurrence of events such as I/O completion, as well 
as time quantum expiration. When scheduled, the context- 
switching and interrupt-processing hardware and software 
ensure that processes are activated quickly. Realtime 
processes can be assigned high priorities to ensure that 
they receive processor time on demand. A process can 
schedule its execution at a given time of day or after an in- 
terval has elapsed, and an appropriately privileged proc- 
ess can modify its priority during execution. 


The system’s memory-management hardware and soft- 
ware ensure that paging, swapping, and dynamic memory 
allocation are both efficient and transparent to the 
programmer. When realtime applications require perform- 
ance control, both paging and swapping can be reduced 
or eliminated by increasing the amount of memory allo- 
cated to a process and by locking a process in memory. 
Because memory management is transparent, programs 
can be written, then tuned for performance after they are 
tested. The system provides a utility program to aid system 
programmers in evaluating the effectiveness of the mem- 
ory-management system for their processes. 


Program Development 

This system provides the system programmer with tools 
that support highly modular program and applications de- 
velopment. By taking advantage of these tools, the pro- 
grammer can build applications quickly and can easily 
modify and extend them later. 
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The system includes editors, compilers, librarians, linkers, 
and debuggers for both the native and compatibility pro- 
gramming environment. All program-development utilities 
can be used either interactively or in batch mode, includ- 
ing the editors and debuggers. The native symbolic de- 
bugger recognizes a command language similar to the 
operating-system command language and uses expres- 
sions similar to the language in which the program being 
debugged was written. 


Executable program images can be built using extensive 
libraries. In the native programming environment, the pro- 
grammer can create libraries of assembler macro defi- 
nitions, of object modules, and of image modules. The 
system also includes the common runtime procedure li- 
brary that provides library functions common to all native 
programming languages. 

All program interfaces to the operating system and its utili- 
ties have uniform calling standards. System programmers 
can add new library procedures to the common runtime 
procedure library and can install them online without mod- 
ifying existing programs and utilities, since all arguments 
are passed using standard data structures. 


Furthermore, user programs can be written to be com- 
pletely device-independent through the system-service 
and command-language logical-naming facilities. All files 
and devices can be identified using arbitrarily defined logi- 
cal names that can be assigned values at runtime. 


THE SYSTEM MANAGER 

A job is normally associated with a user known to the sys- 
tem to have certain privileges, quctas, and resources. The 
system manager authorizes users, plans data access and 
protection, grants privileges, controls resource utilization, 
and analyzes the system’s accounting and performance 
information. 


User Authorization 

The system manager controls use of the system primarily 
by creating user authorization information. This informa- 
tion is recorded in a specially maintained and protected 
file called the user authorization file. Through the User Au- 
thorization Program (AUTHORIZE), the system manager 
can add, delete, modify, or display records in the UAF at 
any time. 


The file contains one entry for each user authorized to ac- 
cess the system. Each entry: 

e Identifies the user. 

e Supplies defaults. 

e Specifies privileges. 

e Limits resource usage. 


User identification consists of a unique user name, a pass- 
word, a default account name, and a user identification 
code (UIC). When logging onto the system, people must 
always enter their user names and passwords to gain ac- 
cess to the system. The password is not displayed on the 
user terminal. Privileged users can change the passwords 
they are assigned as often as they desire. 


This system’s data protection scheme is based on the user 
identification code (UIC) that the system manager assigns. 
A UIC controls each user’s access to the data structures 


protected by UICs, which include both files and the inter- 
process communication facilities such as mailboxes, 
shared areas of memory, lock management services, and 
event flags. 


A UIC consists of a group number and a member number. 
Every user is assigned a UIC, and every data structure is 
assigned both a UIC and a protection code. A protection 
code identifies what types of access are available, and the 
users to which the types are available. There are four types 
of access (read, write, execute, and delete), and there are 
four types of user (owner, group, world, and system). The 
owner is any user that has the same UIC as that assigned 
the data; the group is any user that has the same group 
number as that assigned the data; the world is any user; 
and the system is any user with a group number of one 
through ten. 


Using this protection scheme, a system can have files and 
interprocess communication facilities that are available for 
access only by users having the same UIC, or for access 
only by users in the same group, or for universal access. 
Furthermore, since each data structure has its own protec- 
tion code, it is possible to protect each data structure as- 
signed the same UIC on a different basis. The system UICs 
are generally reserved for system users and system pro- 
grams and data structures. This arrangement enables a 
user to protect a file from access by anyone other than the 
owner or group, but still enables the system to access the 
file for operations such as backup. 


In addition to identifying the user and the set of data struc- 
tures the user can access, the user authorization file sup- 
plies the user with a default file protection, a default direc- 
tory name, and a default device name. When the user 
creates a file, the system assigns the default file protec- 
tion, unless requested otherwise. An owner can modify a 
file’s protection at any time. 


Directory names are arbitrary character strings that iden- 
tify directory files. A directory is simply a file that contains 
a list of filenames and other identification information that 
is used to find files on a volume. The default directory 
name identifies the directory that lists the files the user 
normally accesses. The default device name is the name of 
the device on which the volume containing the files the 
user normally accesses is mounted. 


When the user issues a command to the command inter- 
preter that operates on a file or runs a program that opens 
a file, the file system uses the default directory name and 
default device name to locate the file, unless it is specifi- 
cally requested to use some other directory name or some 
other device name. The user can change the default direc- 
tory and device names for a given session. 


For further information on directories and directory 
structures, refer to the section on Information Manage- 
ment Facilities. 


Privileges 

Each user’s authorization-file entry contains a list of the 
privileges that the user can invoke. These include interpro- 
cess communication and control privileges, performance 
control privileges, file and device access privileges, and 
system operational control privileges. The system man- 
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ager can grant distinct privileges to each user. Table 3-2 
lists some of the privileges. 


Table 3-2 
Privileges Summary 


INTERPROCESS CONTROL 

* Create event flag clusters. 

© Create permanent common-event-flag clusters. 
® Create temporary mailboxes. 

© Create permanent mailboxes. 

® Create global sections. 


® Suspend, resume, wake, and delete processes within 
the same group. 


© Suspend, resume, wake, and delete any process. 
® Create detached processes. 

® Create and delete shared-memory sections. 

® Map to physical pages. 


ACCESS TO FILES AND DEVICES 

® Insert logical names in group-logical-name table. 
® Insert logical names in system-logical-name table. 
® Allocate spooled devices. 

® Obtain exclusive ownership of a shared device. 

® Override volume protection. 

® Issue mount requests. 


PERFORMANCE CONTROL 
® Execute time-critical images. 
® Lock process in memory. 


SYSTEM OPERATION CONTROL 
© Issue operator commands. 

® Set any privilege bits. 

® Set process priority. 


PROGRAM EXECUTION 

© Execute Change Mode to Executive system service. 

® Execute Change Mode to Kernel system service. 

® Bypass file protection. 

® Issue diagnostic functions. 

© Send messages to error logger. 

® Suppress accounting messages. 

® Issue logical and physical I/O functions. 

Privileges are checked when the user executes program 
images. If a user runs an image that attempts to execute a 
function requiring a privilege the user is not granted, the 
image incurs a privilege violation. For example, diagnostic 
programs require the privilege to issue device-level diag- 
nostic functions and the privilege to send messages to the 
error logger. Users who have not been granted these privi- 
leges will receive privilege violation messages if they at- 
tempt to run diagnostics. 


In certain cases, user can run an image that requires 
privileges that the user has not been granted. To let a user 


run an image that requires special privileges, the system 
enables the system manager to install known images. 
When the user runs a known image, the user obtains the 
necessary privileges to execute the functions required by 
the image, but only for the duration of that image’s execu- 
tion. 


Resource Quotas and Limits 
The user authorization file also provides the limits on how 


many system resources a user can tie up while logged on 
the system and provides quotas for how much of a re- 
source a user can use up during an accounting period. 
The system manager can assign user quotas for the maxi- 
mum amount of CPU time accumulated during a given ac- 
counting period. The system manager can also limit the 
amount of dynamic system memory a job can utilize for 
buffers. The system manager can set disk usage quotas 
via the disk quota utility on a per-user, per-volume or vol- 
ume-set basis. VAX/VMS will automatically record usage 
and enforce the assigned quotas during file operation. 
However, each user possessing a private volume controls 
the disk quotas on that volume. The limits imposed by 
VAX/VMS include the maximum number of: 

e Outstanding open files. 

CPU time. 

Outstanding subprocesses created. 

Pages in a process working set. 

Pages in system paging files. 

Outstanding entries in the timer queue. 

Outstanding system buffered I/O requests. 

Bytes in system buffered I/O request. 


Outstanding direct I/O requests. 


Resource Accounting Statistics 

The system maintains an accounting information file for 
collecting cumulative resource usage statistics. The sys- 
tem updates the accounting information file with detailed 
records each time a process terminates. The detailed sta- 
tistics include: 

e Elapsed CPU time. 

Login (connect) time. 

Number of volumes mounted. 

Number of pages printed. 

Largest process virtual size. 

Largest process working set size. 

Number of page faults. 

Number of system buffered I/O requests. 

e Number of direct I/O requests. 


A detail record identifies the account name, user name, 
and user identification code (UIC) to which the statistic ap- 
plies. The accounting information file can be used to cal- 
culate billing information and reporting by account name, 
user name, or UIC. Because the system collects all de- 
tailed records, system managers can define their own 
algorithms for resource-usage billing. 


Performance Analysis Statistics 

The system collects statistics on its activities to help sys- 
tem programmers and managers tune the system for max- 
imum performance. The information collected includes: 
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e System and Job Statistics — indicate the current num- 
ber of processes, interactive users, and batch jobs in the 
system; the date and time the system was booted; and 
the current date and time. 


e Processor Access-Mode Usage — indicates how much 
time is spent executing at each of the access modes, as 
a measure of the type of code being executed and the 
computational workload. 


e Page-Fault Activity — indicates how many and what kind 
of page faults occurred, as a measure of the 
effectiveness of memory management. 

e //O Activity — indicates how many and what kind of I/O 
operations are taking place. 

e Network Activity — indicates network workload (current 
number of nodes in the network, number of bytes trans- 
mitted and received, number of messages transmitted 
and received, number of buffers currently in use, num- 
ber of successful and failed attempts to obtain space for 
network buffers). 


e Response-Time Histograms — indicate the time it takes 
the system to initiate user requests. 


Monitor Utility Program 
The Monitor Utility Program (MONITOR) provides a dy- 


namic display of system performance measurement statis- 
tics on a video display terminal. By typing appropriate 
commands, system users can list information regarding 
I/O system activity, paging, CPU usage, current process 
activity, and other relevant statistics. MONITOR can also 
create a binary recording file that can be played back ata 
later time. 


THE SYSTEM OPERATOR 
Although system operators aren‘t required, it is not un- 


common for a system to have one or more operators, the 
operator being any designee of the system manager who 
has been given the appropriate privileges to perform the 
operator functions. Such functions include: 

System startup and shutdown. 

Job control (change process priorities, kill jobs, etc.). 
Device allocation. 

Volume mount and dismount request servicing. 

Online disk and magnetic tape volume and file backup. 
Spool and batch queue control. 

Software maintenance update installation. 

Diagnostic execution. 


An operator uses the command language to control oper- 
ations, check system status, and run utility programs. 


A special system program, the Operator Communications 
Manager (OPCOM), is the primary operator aid. It collects 
and delivers the messages all users and user programs 
send to the operators. Any operator can respond to user 
requests, and the Operations Communications Manager 
notifies operators of any outstanding requests. 


Spooling and Queue Control 
The operators define the number and kind of input and 


output spool queues in the system. The operators can cre- 
ate output spool queues for any number of devices, in- 


cluding lineprinters, terminals, or magnetic tape. The op- 
erators can also create input queues for spooling batch 
input from a cardreader. 


The operators can assign each queue a priority, merge or 
redirect queues to other devices, and modify the queue 
set-up at any time. It is possible to have more than one 
print queue for the same printer. For example, an operator 
can create a generic printer queue that will collect jobs 
that can be printed on any of a set of printers, and at the 
same time have a print queue for each individual printer. A 
user can issue a print request for a generic printer or a 
particular printer, and the operator can override the user’s 
request. 


A print job can contain a single or multiple files to be 
printed. Print jobs can be submitted by an interactive user, 
batch job, or any program. Print jobs are also automati- 
cally submitted at the end of a batch job. A print job can 
specify the forms type required, the number of copies of 
the job, the job priority, and a “hold until given time” re- 
quest. Each file within a print job has its own copies count, 
and each can have these options: double space, inhibit 
form feed, print a flag page, label each page, or delete af- 
ter printing. The operator can choose whether or not to 
print burst (job separator) pages and can put jobs on inde- 
finite hold, modify the priority of a job, or abort a job. 


Batch Processing 

The system supports multiple-stream, multiple-queue 
batch processing. The operators control how many batch- 
job streams can run concurrently. Batch jobs can be sub- 
mitted by an interactive user, another batch job, or any 
program. When the number of batch jobs submitted 
exceeds the number of streams, the remainder of the 
batch jobs are held in a batch input queue. As with the 
spool queues, the operators can control the batch job 
queue. They can change job priority, hold a job until after a 
given time, hold a job indefinitely, and kill a job. 


Volume mount commands issued in a batch job can re- 
quest a generic device, such as any disk, or a specific de- 
vice, such as Disk Drive Unit 2. The batch job waits until an 
operator satisfies the mount request, while other batch 
jobs proceed. Operators can find out which job has a given 
device. 


Online Software Maintenance 

An operator can incorporate maintenance updates to the 
software without bringing down the system for stand-alone 
use. For example, VAX-11/780 maintenance patches are 
distributed on floppy disks and the operator simply loads 
the console floppy disk drive with the maintenance floppy 
to update the software on disk. Depending on the nature of 
the update, an operator may have to restart the system to 
activate the patched modules. 


System Recovery 

An operator can select manual or automatic system recov- 
ery following a power interruption or hardware or software 
failure. 


On automatic system recovery after power interruption, 
the system determines whether the contents of memory 
are still valid. If so, it restarts as mush of the I/O that was in 
progress at the time of the power interruption and contin- 
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ues operations from the point of interruption. If the con- 
tents of memory are not valid, either because memory bat- 
tery backup was not included in the configuration or 
because the power failure lasted longer than the battery, 
the system will automatically boot itself from disk and exe- 
cute the startup command procedures. 


Error Logging and Reporting 

The error logger is a job that runs continuously. It collects 
errors detected by both hardware and software, including: 
e Device errors. 

e Interrupt timeouts. 

e Interrupts received from nonexistent devices. 

© Memory, translation buffer, and cache parity errors. 


In addition, system software sends complete recovery in- 
formation to the error logger following a power interrup- 
tion or hardware or software failure. 


The error logger writes all messages it receives into an 
error log file, noting vital system statistics at the time of the 
message. The error logger also notes benign events when 
they occur, such as when volumes are mounted and dis- 
mounted, or periodic time stamps indicating that no en- 
tries have occurred for a specified period of time. The er- 
ror logger can accept messages from the operators and 
from any programs privileged to send messages to the er- 
ror logger, at any time. 


The system includes an error-report-generating program 
that converts the information in the log file into a text file 
that can be printed for later study. 


Online Diagnostics 

An operator can run diagnostics to check the operation of 
both hardware and software. An operator can run system 
exercisers and device verification diagnostics while nor- 
mal operations proceed. System exercisers test general 
purpose software and compare the results with known 
answers, reporting any discrepancies to the error logger. 


Operators can run device verification diagnostics either 
stand-alone or concurrent with other processes. Diagnos- 
tics check the peripheral functions, including disk head 
alignment. In addition, fault isolation diagnostics, which 
isolate problems to replaceable units, are available for 
stand-alone use. 


Remote Diagnosis 

If the system is equipped with the remote diagnosis option, 
an operator sets up the system for remote preventive 
maintenance or troubleshooting. When a hardware error is 
detected or suspected, the operator mounts a diagnostic 
disk pack, loads a diagnostic floppy disk in the console, 
sets a switch on the processor console, and calls the local 
DIGITAL service office. An operator does not need to be 
present at the installation once the call is made. The 
DIGITAL Diagnostic Center can then connect to the instal- 
lation, run automated diagnostics, operate the diagnostic 
console manually, and check the error log file. If a problem 
is found, the Field Service engineer can bring the proper 
equipment and replacement modules to make the repairs. 


THE USER ENVIRONMENT TEST PACKAGE 

The User Environment Test Package (UETP) consists of a 
series of tests designed to demonstrate that the hardware 
and software components of a system are in working or- 
der. The UETP consists of six phases: 


© The Initialization Phase — This phase verifies that I/O 
devices are operational via simple read/write opera- 
tions. Users are prompted to supply several parameters 
that define the scope of the test, e.g., number of users to 
be simulated by UETP, amount of information to be dis- 
played at the console, and the number of consecutive 
runs to be made by UETP. 


© The I/O Device Test Phase — In this phase, I/O devices 
undergo comprehensive testing. Terminals and lineprin- 
ters generate pages or screens of output containing 
header information and a test pattern of ASCII charac- 
ters. Disks and magnetic tape are also exercised. Files 
are created on mounted volumes. Data are then written 
to the files. The test then checks the written data for er- 
rors and erases the files. 


e The Native-Mode Phase — This phase includes tests 
that exercise software services provided explicitly for 
VAX/VMS. It exercises VAX/VMS system services, na- 
tive-mode utilities such as the Symbolic Debugger and 
Image File Patch Utility, VAX-11 RMS, and SORT. 


The System Load Test Phase — This phase creates a 
number of detached processes that simulate the action 
of a group of users concurrently issuing commands 
from terminals; it tests the system’s ability to handle 
various levels of utilization. 


The Compatibility Mode Test Phase — This phase tests 
most RSX utilities running in compatibility mode on 
VAX/VMS. 


Termination Phase — I|n this phase, temporary files are 
deleted and other cleanup activities are performed. If 
multiple runs were requested during the initialization 
phase, then the UETP is restarted and control is passed 
directly to the device test phase. 
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A VAX processor executes variable-length instructions in native mode and 
nonprivileged PDP-11 instructions in compatibility mode. The VAX processor 
includes integral memory management, sixteen 32-bit registers, 32.interrupt 
priority levels, an intelligent console, a programmable realtime clock, and a 
time-of-day and date clock. 


The VAX native instruction set provides 32-bit addressing enabling the proces- 
sor to address up to four billion bytes of virtual address space. The processor’s 
memory management hardware includes mapping registers used by the oper- 
ating system, page protection by access mode, and an address translation 
buffer that eliminates extra memory accesses during virtual to physical address 
translation. 


VAX also provides sixteen 32-bit general registers that can be used for tempo- 
rary storage or as accumulators, index registers, and base registers. Four 
registers have special significance are the Program Counter and three regis- 
ters that are used to provide an extensive procedure CALL facility. The proces- 
sor Offers a variety of addressing modes that use the general registers to iden- 
tify instruction operand locations, including an indexed addressing mode that 
provides a true post-indexing capability. 

The native instruction set is highly bit-efficient. It includes integral decimal, 
character-string, and floating-point instructions, as well as integer, logical, and 
bit field instructions. Instructions and data are of variable length and can start 
at any arbitrary byte boundary or, in the case of bit fields, at any arbitrary bit in 
memory. Floating-point instruction execution can be enhanced by an optional 
floating-point accelerator. 


The I/O subsystem consists of the processor’s internal bus and the UNIBUS 
and MASSBUS interfaces. 


INTRODUCTION 


This section is divided into two parts. The first discusses 
the architecture of a VAX processor. The second dis- 
cusses VAX processor implementation details. 


VAX ARCHITECTURE 

The following sections discuss the architecture, that is, the 
programming characteristics of the processing system as 
seen from the general user’s and the operating system’s 
viewpoint. 

PROCESSING CONCEPTS FOR USER 
PROGRAMMING 

A program is a stream of instructions and data that a user 
can request the operating system to translate, link, and ex- 
ecute. An executable program is called an image, to distin- 
guish it from source and object programs. When a user 
runs an image, the context in which the image is executed 
is called a process. A process is the complete unit of exe- 
cution in this computer system; typically, it runs several 
images, one after another. Process context includes the 
state of the image it is currently executing and includes the 
image’s allowable limitations which primarily depend on 
the privileges of the user executing the image. 


The next few pages introduce some of the concepts that 
concern assembly language programmers in general, in- 
cluding addressing, data types, instruction sets, and other 
programming aspects of the processor. Further details on 
these programming characteristics follow this introduc- 
tion. 


Process Virtual Address Space 

Most data are located in memory using the address of an 
eight-bit byte. The programmer uses a 32-bit virtual ad- 
dress to identify a byte location. This address is called a 
virtual address because it is not the real address of a 
physical memory location. It is translated into a real ad- 
dress by the processor under operating system control. A 
virtual address is not a unique address of a location in 
memory, aS are physical memory addresses. Two pro- 
grams using the same virtual address might refer to two 
different physical memory locations, or might refer to the 
same physical memory location using different virtual ad- 
dresses. 


The set of all possible 32-bit virtual addresses is called 
virtual address space. Conceptually, virtual address space 
can be yiewed as an array of byte locations labelled from 0 
to 29, an array that is approximately four billion bytes in 
length. This address space is divided into sets of virtual 
addresses designated for certain uses. The set of virtual 
addresses designated for use by a process, including an 
image it executes, is one half of the total virtual address 
space. Addresses in the remaining half of virtual address 
space are used to refer to locations maintained and pro- 


tected by the operating system. 


Instruction Sets 

At any one time, the processor’s instruction interpretation 
hardware can be set to either of two modes: native mode 
or compatibility mode. In native mode the processor exe- 
cutes a large set of variable-length instructions, recog- 
nizes a variety of data types, and uses sixteen 32-bit 
general purpose registers. In compatibility mode the proc- 
essor executes a set of PDP-11 instructions, recognizes in- 
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teger data, and uses eight 16-bit general purpose regis- 
ters. While native mode is the primary instruction 
execution state of the machine and compatibility mode the 
secondary state, their instruction sets are closely related, 
and their programming characteristics are very similar. A 
user process can execute both native mode images and 
compatibility mode images. 


A native instruction consists of an operation code (op- 
code) and zero or more operands that are described by 
data type and addressing mode. The native instruction set 
is based on over 200 different kinds of operations, each of 
which can be addressed in any one of several ways. Thus, 
the native instruction set offers a tremendous number of 
instructions from which to choose. 


In spite of the large number of instructions, the native in- 
struction set is a natural programming language that is 
very easy to learn. Many of the instructions correspond 
directly to high-level language statements, and the assem- 
bler mnemonics are readily associated with the instruction 
function. 


To choose the appropriate instruction, it is only necessary 
to become familiar with the operations, data types, and ad- 
dressing modes. For example, the ADD operation can be 
applied to any of several sizes of integer, floating-point, or 
packed-decimal operands, and each operand can be ad- 
dressed directly in a register, directly in memory, or 
indirectly through pointers stored in registers or memory 
locations. 


Registers and Addressing Modes 

A register is a location within the processor that can be 
used for temporary data storage and addressing. The as- 
sembly language programmer has sixteen 32-bit general 
registers available for use with the native instruction set. 
Some of these registers have special significance. For ex- 
ample, one register is designated as the Program Counter; 
it contains the address of the next instruction to be exe- 
cuted. Three general registers are designated for use with 
procedure linkages; they are the Stack Pointer, the 
Argument Pointer, and the Frame Pointer. 


An instruction operand can be located in main memory, in 
a general register, or in the instruction stream itself. The 
way in which an operand location is specified is called the 
operand addressing mode. The processor offers a variety 
of addressing modes and addressing mode optimizations. 
There is one addressing mode that locates an operand ina 
register. There are six addressing modes that locate an 
operand in memory using a register to: 

® Point to the operand 

e Point to a table of operands 


e Point to a table of operand addresses 


Additionally, there are six addressing modes that are in- 
dexed modifications of the addressing modes that locate 
an operand in memory. Finally, there are two addressing 
modes that identify the location of the operand in the in- 
struction stream; one is for constant data and the other for 
yranch-instruction addresses. 


Data Types 
The data type of an instruction operand identifies how 
many bits of storage are to be treated as a unit and what 


the interpretation of that unit is. The processor’s native in- 
struction set recognizes four primary data types: integer, 
floating-point, packed-decimal, and character-string. For 
each of these data types, the selection of operation im- 
mediately tells the processor the size of the data and its 
interpretation. The processor can also manipulate a fifth 
data type, the bit field, in which the user defines the size of 
the field and its relative position. In addition, the processor 
supports two types of linked-list queue structures. 


There are several variations on the four primary data 
types. Table 4-1 provides a summary of the data types 
available, each of which is illustrated in Figure 4-1. Integer 
data are stored as a binary value in either byte, word, long- 
word, or, in some cases, in quadword or octaword format. 
A byte is eight bits; a word is two bytes; a longword is four 
bytes; a quadword is eight bytes; and an octaword is six- 
teen bytes. The processor can interpret an integer as ei- 
ther a signed value or an unsigned value. The sign is 
determined by the high-order bit. 


Floating-point values are stored using a signed exponent 
and a binary normalized fraction. The normalization bit is 
not represented. Four types of floating-point data formats 
are provided. The two PDP-11-compatible formats 


(F_floating and D_floating) are standard on all VAX family 
processors. Two extended range formats (G_floating and 
H_floating) are available as options on VAX family proces- 
sors. F_floating and D_floating are four and eight bytes 
long respectively, with an eight-bit excess 128 exponent. 
The effective 24-bit fraction of F_floating yields approxi- 
mately seven decimal digits of precision. The 56-bit frac- 
tion of D_floating yields approximately 16 decimal digits of 
precision. G_floating is also eight bytes in length, but has 
an 11-bit excess 1,024 exponent and effectively 53 bits of 
fraction. Its precision is approximately 15 decimal digits. 


H_floating is 16 bytes in length with a 15-bit excess 16,384 
exponent and 113-bit fraction. Its precision is approxi- 
mately 33 decimal digits. 


Packed-decimal data are stored in a string of bytes. Each 
byte is divided into two four-bit nibbles. One decimal digit 
is stored in each nibble. The first, or high-order, digit is 
stored in the high-order nibble of the first byte; the second 
digit is stored in the low-order nibble of the first byte; the 
third digit is stored in the high-order nibble of the second 
byte; and so on. The sign of the number is stored in the 
low-order nibble of the last byte of the string. 


Table 4-1 
Data Types 


DATA TYPE SIZE RANGE (decimal) 


Integer 

8 bits 

16 bits 

32 bits 

64 bits 
128 bits 


Byte 

Word 
Longword 
Quadword 
Octaword 


0 to 255 

0 to 65535 

0 to 2°7—-1 

0 to 2°*—1 
Oto 2‘ —4 


—128 to +127 
—32768 to +32767 
S21 rey 1 
—253 to +263—1 
—2127 to +2127 


F_and D_floating point +2.9 X 10°’ to 1.7 x 10° 


F_floating point 32 bits 


D_floating 64 bits 


approximately seven decimal 
digits precision 


approximately sixteen decimal 
digits precision 


G_floating point +0.56 X 10°2°8 to 0.9 x 10308 


G_floating 64 bits approximately fifteen decimal 
digits precision 
H_floating point +0.84 X 1074952 to 40.59 X 10499? 


H_floating 


Packed Decimal 
String 


Character String 


Variable-length 
Bit Field 


Numeric String 


>= 2 longwords/ 
queue entry 


Queue 


128 bits 
0 to 16 bytes numeric, two digits per byte 
(31 digits) sign in low half of last byte 


0 to 65535 bytes one character per byte 


0 to 32 bits dependent on interpretation 


0 to 31 bytes (DIGITS) 
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approximately thirty-three 
decimal digits precision 


—10%! —1 to +103! -1 


Queue entries at arbitrary 
displacement in memory 


LONGWORD 
31 0 
QUADWORD 
1 0 
DA 
7: A+t4 
63 32 
OCTAWORD 
31 0 
DA 
A+4 
A+8 
A+12 
127 % 
F__ FLOATING D_ FLOATING 
15 7 6 0 15 7 6 0 
EXPONENT FRACTION EXPONENT FRACTION 
FRACTION FRACTION 
31 16 
FRACTION 
G_ FLOATING FRACTION 
1514 4 3 0 63 48 
EXPONENT FRACTION |: 
FRACTION 
FRACTION H _ FLOATING 
FRACTION 
EXPONENT ZA 
FRACTION :A+2 
PACKED DECIMAL STRING (+123) 
FRACTION DAt4 
FRACTION :A+6 
FRACTION :A+8 
FRACTION :A+10 
FRACTION A412 
FRACTION SA+l4 
VARIABLE-LENGTH BIT FIELD 
P+S P+S-] Pe. Pe] 0 
A=ADDRESS S-1 0 
Figure 4-1 


Data Type Representations 
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Character data are simply a string of bytes containing any 
binary data — for example, ASCII codes. The first charac- 
ter in the string is stored in the first byte; the second char- 
acter is stored in the second byte; and so on. A character 
string that contains ASCII codes for decimal digits is called 
a numeric string. 


The address of any data item is the address of the first byte 
in which the item resides. All integer, floating-point, 
packed-decimal, and character-string data can be stored 
starting on an arbitrary byte boundary. A bit field, however, 
does not necessarily start on a byte boundary. A field is 
simply a set of contiguous bits (0-32), the starting bit loca- 
tion of which is identified relative to a given byte address 
or register. The native instruction set can interpret a bit 
field as a signed or unsigned integer. 


The VAX queue data types consist of circular doubly 
linked lists. A queue entry is specified by its address. Each 
queue entry is linked to the next entry via a pair of long- 
words. The first longword is the forward link; it specifies 
the location of the succeeding entry. The second longword 
is the backward link; it specifies the location of the preced- 
ing entry. VAX processors support two queue types ac- 
cording to the nature of the links: absolute and self-rela- 
tive. An absolute link contains the absolute address of the 
entry that it points to. A self-relative link contains a 
displacement from the address of the queue entry. 


Stacks, Subroutines, and Procedures 

A stack is an array of consecutively addressed data items 
that are referenced on a last-in, first-out basis using a gen- 
eral register. Data items are added to and removed from 
the low address end of the stack. A stack grows toward 
lower addresses as items are added and shrinks toward 
higher addresses as items are removed. 


A stack can be created anywhere in the user’s program 
address space. Any register can be used to point to the 
current item on the stack. The operating system, however, 
automatically reserves portions of each process address 
space for stack data structures. User software references 
its stack data structure, called the user stack, through a 
general register designated as the Stack Pointer. When 
the user runs a program image, the operating system au- 
tomatically provides the address of the area designated 
for the user stack. 


A stack is an extremely powerful data structure because it 
can be used to pass arguments to routines efficiently. In 
particular, the stack structure supports reentrant routines 
because the processor can handle routine linkages auto- 
matically, using the Stack Pointer. Routines can also be re- 
cursive because arguments can be saved on the stack for 
each successive call of the same routine. 


The processor provides two kinds of routine call instruc- 
tions: those for subroutines and those for procedures. In 
general, a subroutine is a routine entered using a Jump- 
to-Subroutine or Branch-to-Subroutine instruction, while a 
procedure is a routine entered using a Call instruction. 


The processor provides more elaborate routine linkages 
for procedures than for subroutines. The processor auto- 
matically saves and restores the contents of registers to be 
preserved across procedure calls. The processor provides 
two methods for passing argument lists to called pro- 
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cedures: by passing the arguments on the stack, or by 
passing the address of the arguments elsewhere in mem- 
ory. The processor also constructs a “journal” of pro- 
cedure-call nesting by using a general register as a pointer 
to the place on the stack where a procedure has its linkage 
data. This record of each procedure’s stack data, known 
as its stack frame, enables proper returns from pro- 
cedures, even when a procedure leaves data on the stack. 
in addition, user and operating system software can use 
the stack frame for tracing back through nested calls to 
handle errors or debug programs. 


Condition Codes 

A user program can test the outcome of an arithmetic or 
logical operation. The processor provides a set of condi- 
tion codes and branch instructions for this purpose. The 
condition codes indicate whether the previous arithmetic 
or logical operation produced a negative or zero result or 
whether there was a carry or borrow or an overflow. There 
are a variety of branch on condition instructions: those for 
overflow and carry or borrow and those for signed and un- 
signed relational tests. 


Exceptions 

Certain situations may require that the results of an opera- 
tion be tested either by the user or by the processor 
directly. The processor recognizes many events for which 
it must test directly; it will automatically change the normal 
flow of the user program when such events occur. These 
events, called exceptions, are the direct result of executing 
a specific instruction. Exceptions also include errors auto- 
matically detected by the processor, such as improperly 
formed instructions. 


All exceptions trap to operating-system software. There 
are essentially no fatal exceptions. All exceptions either 
wait for the instruction that caused them to complete be- 
fore trapping or they restore the processor to the state it 
was in just prior to executing the instruction that caused 
the exception. In either case, the instruction can be retried 
after the cause of the exception is cleared. Depending on 
the exception, it may be desirable to correct the situation 
and continue. If it is not, the operating system issues an 
appropriate message and aborts the instruction stream in 
progress. To continue, the user can request the operating- 
system software to automatically start execution of a con- 
dition handler when an exception occurs. 


USER PROGRAMMING ENVIRONMENT 

A process context includes the definition of the virtual ad- 
dress space in which it executes an image. An image exe- 
cuting within a process context controls its execution 
through the use of one of the instruction sets, the general 
purpose registers, and the Processor Status Word. These 
hardware resources are discussed in detail in the following 
sections. 


Process Virtual Address Space Structure 

As mentioned earlier, certain sets of virtual addresses in 
virtual address space are designated for particular uses. 
The processor and operating system provide a multipro- 
gramming environment by dividing virtual address space 
into two halves; one half is for addressing context-depen- 
dent code and data, and the other is for addressing con- 
text-independent code and data. 


The first half is called per-process space (or, more simply, 
“process space’’), which is capable of addressing 
approximately two billion bytes. An image executing in the 
context of a process and the operating system on behalf of 
the process, both use addresses in process space to refer 
to code and data particular to that process context. A 
process cannot represent virtual addresses in any process 
space except its own. Thus, code and data belonging toa 
process are automatically protected from other processes 
in the system. 


The second half of virtual address space is called system 
space. The operating system assigns specific meanings to 
addresses in system space. The significance of any ad- 
dress in system space is the same for every process, inde- 
pendent of process context. Although most locations re- 
ferred to by system space addresses are protected from 
access by user images, if two images executing in different 
process contexts do use an address in system space, the 
address always refers to the same physical location in 
memory. 


Process space is further subdivided into two equal re- 
gions. Addresses in the first region, called the program re- 
gion, are used to identify the location of image code and 
data. Addresses in the second region, called the contro! 
region, are used to refer to stacks and other temporary 
program-image and permanent process-control informa- 
tion maintained by the operating system on behalf of the 
process. Program region addresses are allocated from 
address 0 up, and control region addresses are allocated 
from address 23'—1 down. 


System space is also subdivided into two equal regions. 
The operating system assigns the system region ad- 


dresses for linkages to its service procedures, for memory 
management data, and for I/O processing routines. The 
second region is presently unused. 


General Registers 

Instruction operands are often either stored in the proces- 
sor’s general registers or accessed through them. The six- 
teen 32-bit programmable general registers are labelled 
RO through R15 (in decimal). Registers can be used for 
temporary storage, accumulators, base registers, and in- 
dex registers. A base register contains the address of the 
base of a software data structure such as a table, and an 
index register contains a logical offset into a data struc- 
ture. 


Whenever a register is used to contain data, the data are 
stored in the register in the same format as would appear 
in memory. If a quadword or double-floating datum is 
stored in a register, it is actually stored in two adjacent 
registers. For example, storing a double floating number in 
register R7 loads both R7 and R8. 


Some registers have special significance, depending on 
the instruction being executed. Registers R12 through R15 
have special significance for many instructions and, there- 
fore, have special labels. These special registers are: 


e The Program Counter (PC or R15), which contains the 
address of the next byte to be processed in the instruc- 
tion stream. 

e The Stack Pointer (SP or R14), which contains the ad- 
dress of the top of a stack maintained for subroutine and 
procedure Calls. 

e The Frame Pointer (FP or R13), which contains the 
address of the base of a software data structure stored 


Table 4-2 
Addressing Modes: Assembler Syntax 


Literal s° # constant 
(Immediate) I’ 
Rn 


| Register PR 


Register Deferred (Rn) 
Autodecrement — (Rn) 


Autoincrement Deferred 
(Absolute) 


Displacement 


Displacement Deferred 


n= Othrough 15 
x = Othrough 14 


@ (Rn) + 
@ # address 


Indexed 
[Rx] 


displacement (Rn) 
address 


displacement (Rn) 
address 


on the stack called the stack frame, maintained for pro- 
cedure Calls. 


e The Argument Pointer (AP or R12), which contains the 
address of the base of a software data structure called 
the argument list, maintained for procedure calls. 


In addition, the first six registers, RO through R5, have spe- 
cial significance for character-string and packed-decimal 
string instructions and the Cyclic Redundancy Check and 
Polynomial Evaluation instructions. These instructions use 
these registers to store temporary results and, upon com- 
pletion, leave results in the registers that a program can 
use as the operands of subsequent instructions. 


A register’s special significance does not preclude its use 
for other purposes, except for the Program Counter. The 
Program Counter can not be used as an accumulator, asa 
temporary register, or as an index register. In general, 
however, most users do not use the Stack Pointer, Argu- 
ment Pointer, or Frame Pointer for purposes other than 
those designated. 


Addressing Modes 

The processor’s addressing modes allow almost any oper- 
and to be stored in a register or in memory, or as an im- 
mediate constant. Table 4-2 summarizes the addressing 
modes. 


There are seven basic addressing modes that use the gen- 

eral registers to identify the operand location. They in- 

clude: 

e Register mode, in which the register contains the oper- 
and. 


e Register-Deferred mode, in which the register contains 
the address of the operand. 


e Autodecrement mode, in which the contents of the 
register are first decremented by the size of the operand 
and then used as the address of the operand. The size of 
the operand (in bytes), which is given by the data type of 
the instruction operand, depends on the instruction. For 
example, the Clear Word instruction uses a size of two, 
since there are two bytes per word. 


e Autoincrement mode, in which the contents of the regis- 
ter are used as the address of the operand, and then in- 
cremented by the size of the operand. If the Program 
Counter is the specified register, the mode is called Im- 
mediate mode. 


e Autoincrement-Deferred mode, in which the contents of 
the register are used as the address of a location in 
memory containing the address of the operand and then 
are incremented by four (the size of an address). If the 
Program Counter is the specified register, the mode is 
called Absolute mode. 


Displacement mode, in which the value stored in the 
register is used as a base address. A byte, word, or 
longword signed constant is added to the base address, 
and the resulting sum is the effective address of the op- 
erand. 


Displacement-Deferred mode _ n which the value stored 
in the register is used as the base address of a table of 
addresses. A byte, word, or longword signed constant is 
added to the base address, and the resulting sum is the 
address of the location that contains the actual address 
of the operand. 
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Of these seven basic modes, all except register mode can 
be modified by an index register. When an index register is 
used with a basic mode to identify an operand, the ad- 
dressing mode is the name of the basic mode with the suf- 
fix “indexed.” For example, the indexed addressing mode 
for register deferred is called “register deferred indexed” 
mode. In addition to the seven basic addressing modes 
that use registers, the processor recognizes six indexed 
addressing modes. 


In an indexed addressing mode, one register is used to 
compute the base address of a data structure, and the 
other register is used to compute an index offset into the 
data structure. To obtain the operand’s effective address 
in an indexed addressing mode, the processor computes 
the base operand address provided by one of the basic 
addressing modes (except register mode); takes the value 
stored in the index register and multiplies it by the given 
operand size; adds the resultant value to the operand ad- 
dress. The index register contents, which are not affected, 
can be used for subsequent processing operations. 


The processor also provides literal-mode addressing, in 
which an unsigned six-bit field in the instruction is in- 
terpreted as an integer or floating-point constant. 


The variety of addressing modes enables the assembly 
language programmer to write, and high-level language 
compilers to produce, very compact code. For example, li- 
teral mode is a very efficient way to specify small con- 
stants. The six-bit field is interpreted as an integer when 
used with integer operations, and can therefore express 
the constants 0 through 63 (decimal). The six-bit field is in- 
terpreted as a floating-point constant when used in float- 
ing-point operations, in which three bits express an expo- 
nent and three a fraction. 


The autoincrement and autodecrement modes enable 
automatic stepping through tables. Displacement mode 
enables generation of offsets into a table, with a choice of 
either short or long displacements. The deferred modes 
enable the user to maintain tables of operand addresses 
instead of the operands themselves. 


The indexed addressing modes allow indexing into tables 
with a step size automatically determined by the operand. 
As in autoincrement and autodecrement addressing, the 
index is calculated in the context of the operand data type. 
This means that the user can easily access several tables 
of differing data types, using the same index key. 


Furthermore, because the indexed addressing modes en- 
able specification of the base operand address using any 
mode that generates an actual address (that is, any mode 
except register or literal), the user has the ability to con- 
struct double indexing. The base address can be selected 
from a table of base addresses, using displacement-de- 
ferred mode; and then use an index register to provide the 
Offset into the particular table selected. 


Thus, the processor’s addressing modes allow 
considerable flexibility in the arrangement and processing 
of data structures. A data structure’s design does not have 
to be tied to its processing method to be efficient. 


Program Counter 
A native-mode instruction has a variable-length format, 
and instructions are thought of as byte-aligned. A variable- 


AUTODECREMENT MODE, MOVE LONG INSTRUCTION 


MOVL -(R3),R4 


BEFORE INSTRUCTION EXECUTION 


ADDRESS SPACE 


00001014 | 10 
00001015 
00001016 
00001017 


AFTER INSTRUCTION EXECUTION 


00003000 
00003001 
00003002 


R3 R4 
00001018 00000000 


R3 R4 
00001014 CE543210 


MACHINE CODE: (ASSUMED STARTING LOCATION 00003000) 


Loe" | OPCODE FOR MOVE LONG INSTRUCTION 
AUTODECREMENT MODE, REGISTER R3 
REGISTER MODE, REGISTER R4 


Figure 4-2 
Instruction Representation 


length format not only makes code more compact, it also 
means that the instruction set can be extended easily. The 
opcode for the operation is either one or two bytes long 
and is followed by zero to six operand specifiers, depend- 
ing on the instruction. An operand specifier can be one or 
several bytes long, depending on the addressing mode. 
Figure 4-2 illustrates the representation of an instruction 
as a string of bytes. Just before the processor begins to 
execute an instruction, the Program Counter contains the 
address of the first byte of the next instruction. The way in 
which the Program Counter is updated is totally transpar- 
ent to the programmer. 


The Program Counter itself can be used to identify oper- 
ands. The assembler translates many types of operand 
references into addressing modes, using the Program 
Counter. Autoincrement mode using the Program Coun- 
ter, or immediate mode, is used to specify inline constants 
other than those available with literal-mode addressing. 
Autoincrement-deferred mode using the Program Coun- 
ter, or absolute mode, is used to reference an absolute ad- 
dress. Displacement and displacement-deferred modes 
using the Program Counter are used to specify an oper- 
and, using an offset from the current location. 


Program Counter addressing enables the user to write po- 
sition-independent code. Position-independent code can 
be executed anywhere in virtual address space after it has 
been linked, since program linkages can be identified as 
absolute locations in virtual address space, and, since all 
other addresses can be identified relative to the current in- 
struction. 


Stack Pointer, Argument Pointer and Frame Pointer 

The Stack Pointer is a register specifically designated for 
use with stack structures. Autodecrement-mode address- 
ing using the Stack Pointer can be used to place items on 
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the stack. Auoincrement mode can be used to remove 
items from the stack. To reference and modify the top ele- 
ment on a stack without removing it, use register-deferred 
mode, and to reference other elements of the stack, use 
displacement-mode addressing. 


The processor designates Register 14 as the Stack Pointer 
for use with both the subroutine Branch or Jump instruc- 
tions, and the procedure Call instructions. On routine en- 
try, the processor automatically saves the address of the 
instruction that follows the routine call on the stack. It uses 
the Program Counter and the Stack Pointer to perform the 
operation. Before entering the subroutine, the Program 
Counter contains the address of the instruction following 
the Branch, Jump, or Call instruction; the Stack Pointer 
contains the address of the last item on the stack. The 
processor pushes the contents of the Program Counter on 
the stack. Returning from a subroutine, the processor au- 
tomatically restores the Program Counter by popping the 
return address off the stack. 


Also, for the procedure Call instructions, the processor de- 
signates Register 12 as an Argument Pointer and Register 
13 as a Frame Pointer. The Argument Pointer is used to 
pass the address of the argument list to a called pro- 
cedure, and the Frame Pointer is used to keep track of 
nested Call instructions. 


An argument list is a formal data structure containing the 
arguments required by the procedure being called. Argu- 
ments can be actual values, addresses of data structures, 
or addresses of other procedures. An argument list can be 
passed in either of two ways: by passing only its address or 
by passing the entire list on the user stack. The first 
method is used to pass long argumentlists or lists that are 
to be preserved. The second method is generally used 
when calling procedures that do not require arguments or 
when building an argument list dynamically. 


15 


DECIMAL OVERFLOW TRAP ENABLE 


TRACE FAULT ENABLE 
NEGATIVE CONDITION CODE 
ZERO CONDITION CODE 
OVERFLOW CONDITION CODE 
CARRY (BORROW) CONDITION CODE 
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7 6 5 4 3 2 ] 0 
FLOATING UNDERFLOW EXCEPTION =o 
INTEGER OVERFLOW TRAP ENABLE 


Figure 4-3 
Processor Status Word 


When issuing a procedure Call instruction, the processor 
uses the Argument Pointer to pass arguments to the pro- 
cedure. If arguments were passed on the stack, the proc- 
essor automatically pops the arguments off on return from 
the procedure. 


The importance of the way the Call instructions work is that 
nested calls can be traced back to any previous level. The 
Call instructions always keep track of nested calls by using 
the Frame Pointer register. The Frame Pointer contains 
the address on the stack of the items pushed on the stack 
during the procedure call. The set of items pushed on the 
stack during a procedure call is known as a call frame or 
Stack frame. Since the previous contents of the Current 
Frame register are saved in each call frame, the nested 
frames form a linked data structure that can be unwound 
to any level when an error or exception condition occurs in 
any procedure. 


Processor Status Word 

The Processor Status Word (a portion of the Processor 
Status Longword) is a special processor register that a 
program uses to check its status and to control synchro- 
nous error conditions. The Processor Status Word, illu- 
strated in Figure 4-3, contains two sets of bit fields: 

e Thecondition codes 


e The trap enable flags 


The condition codes indicate the outcome of a particular 
logical or arithmetic operation. For example, the Subtract 
instruction sets the Negative bit if the result of the subtrac- 
tion operation produced a negative number, and it sets the 
Zero bit if the result produced zero. The Branch on 
Condition instructions can be used to transfer control to a 
code sequence that handles the condition. 


There are two kinds of exceptions that concern the user 
process: trace faults and arithmetic exceptions. The trace 
fault is used by debugging programs or performance eva- 
luators. Arithmetic exceptions include: 

Integer, floating-point, or decimal-string overflow, in 
which the result was too large to be stored in the given 
format. 

Integer, floating-point, or decimal-string divide by zero, 
in which the divisor supplied was zero. 

Floating-point underflow, in which the result was too 
small to be expressed in the given format. 
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Of the arithmetic exceptions, integer overflow, floating un- 
derflow, and decimal-string overflow can be handled in 
one of two ways. By clearing the exception enable bits in 
the Processor Status Word, the processor can be directed 
to ignore integer and decimal-string overflow and floating 
underflow. The user can check for these conditions either 
by testing the condition codes (except for underflow) using 
the Branch on Condition instructions or by enabling the 
exception bits. By enabling the exception bits, the proces- 
sor treats integer and decimal-string overflow and floating 
underflow as exceptions. In any case, floating overflow and 
divide-by-zero exceptions are always enabled. 


Handling Exceptions 

When an exception occurs, the processor immediately 
saves the current state of execution and traps to the oper- 
ating system. The operating system automatically 
searches for a procedure that wants to handle the excep- 
tion. Procedures that respond to exceptions are called 
condition handlers. The user can declare a condition 
handler for an entire image and for each individual pro- 
cedure called. In addition, because the processor keeps 
track of nested calls using the Frame Pointer register, it is 
possible to declare condition handlers for procedures that 
call other procedures in which exceptions might occur. 
The operating system automatically traces back through 
call frames to find a condition handler that wants to handle 
an exception that occurs. 


NATIVE INSTRUCTION SET 

The instruction set that the processor executes is selected 
under operating-system control to either native mode or 
compatibility mode. The native-mode instruction set is 
based on over 200 different opcodes. The opcodes can be 
grouped into classes based on their function and use. In- 
structions used to manipulate the general data types in- 
clude: 

Integer and logical instructions 

e Floating-point instructions 

Packed-decimal instructions 

Character-string instructions 


Bit-field instructions 


Instructions that are used to manipulate special kinds of 
data include: 

e Queue-manipulation instructions 

e Address-manipulation instructions 

e User-programmed general register control instructions 


Instructions that provide basic program flow control and 
enable the user to call procedures are: 

e Branch, jump, and case instructions 

e Subroutine call instructions 

e Procedure call instructions 


Table 4-3 lists the basic instruction operations in order by 
these classifications. Instructions that enable operating 
system procedures to provide user-mode processes with 
services requiring privilege are listed in the table, but dis- 
cussed in the system programming environment section. 


Instructions that are singular in the functions they provide 
are listed last. The following paragraphs describe the func- 
tions of most of the instructions within each class. For fur- 
ther information on the instruction set, refer to the VAX-77 
Architecture Handbook. 


Integer and Floating-Point Instructions 

The logical and integer arithmetic instructions illustrate 
how the opcodes, data types, and addressing modes can 
be combined in an instruction. Most of the operations pro- 
vided for integer data are also provided for floating-point 
and packed-decimal data. Exceptions are the strictly logi- 
cal operations for integer data (such as bit clear, bit set, 
and complement), the multiword arithmetic instructions 
for integer data (such as Add/Subtract with Carry and Ex- 
tended Multiply and Extended Divide), and the Extended 
Modulus and Polynomial instructions for floating-point 
data. 


Table 4-3 
Instruction Set Summary 


Integer and Floating Point Logical Instructions 


MOV_* Move (B,W,L,F,D,G,H,Q,0)** 

MNEG_ Move Negated (B,W,L,F,D,G,H) 

MCOM_ Move Complemented (B,W,L) 

MOVZ_ Move Zero-Extended (BW,BL,WL) 

CLR_ Clear (B,W,L=F,Q=D=G,O=H) 

CVT_ Convert (B,W,L,F,D,G,H)(B,W,L,F,D,G,H) 
except BB,WW,LL,FF,DD,GG,HH,DG, 
and GD 

CVTR_L Convert Rounded (F,D,G,H) to Longword 

CMP_ Compare (B,W,L,F,D,G,H) 

TST_ Test (B,W,L,F,D,G,H) 

BIS_2 Bit Set (B,W,L) 2-Operand 

BIS_3 Bit Set (B,W,L) 3-Operand 

BIC_2 Bit Clear (B,W,L) 2-Operand 

BIC_3 Bit Clear (B,W,L) 3-Operand 

BIT_ Bit Test (B,W,L) 

XOR_2 Exclusive OR (B,W,L) 2-Operand 

XOR_3 Exclusive OR (B,W,L) 3-Operand 

ROTL Rotate Longword 


Integer and Floating Point Arithmetic Instructions 


INC_ Increment (B,W,L) 

DEC_ Decrement (B,W,L) 

ASH_ Arithmetic Shift (L,Q) 

ADD_2 Add (B,W,L,F,D,G,H) 2-Operand 
ADD_3 Add (B,W,L,F,D,G,H) 3-Operand 
ADWC Add with Carry 

ADAWI Add Aligned Word Interlocked 
SUB_2 Subtract (B,W,L,F,D,G,H) 2-Operand 
SUB_3 Subtract (B,W,L,F,D,G,H) 3-Operand 
SBWC Subtract with Carry 

MUL_2 Multiply (B,W,L,F,D,G,H) 2-Operand 
MUL_3 Multiply (B,W,L,F,D,G,H) 3-Operand 
EMUL Extended Multiply 

DIV_2 Divide (B,W,L,F,D,G,H) 2-Operand 
DIV_3 Divide (B,W,L,F,D,G,H) 3-Operand 
EDIV Extended Divide 

EMOD_ Extended Modulus (F,D,G,H) 

POLY_ Polynomial Evaluation (F,D,G,H) 
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Packed Decimal Instructions 


MOVP Move Packed 
CMPP3 Compare Packed 3-Operand 
CMPP4 Compare Packed 4-Operand 


ASHP Arithmetic Shift Packed and Round 


ADDP4 Add Packed 4-Operand 
ADDP6 Add Packed 6-Operand 
SUBP4 Subtract Packed 4-Operand 
SUBP6 Subtract Packed 6-Operand 
MULP Multiply Packed 

DIVP Divide Packed 

CVTLP Convert Long to Packed 
CVTPL Convert Packed to Long 
CVTPT Convert Packed to Trailing 
CVTTP Convert Trailing to Packed 
CVTPS Convert Packed to Separate 
CVTSP Convert Separate to Packed 
EDITPC Edit Packed to Character String 


Character String Instructions 


MOVC3 Move Character 3-Operand 
MOVCS5 Move Character 5-Operand 
MOVTC Move Translated Characters 
MOVTUC Move Translated Until Character 
CMPC3 Compare Characters 3-Operand 
CMPC5 Compare Characters 5-Operand 
LOCC Locate Character 

SKPC Skip Character 

SCANC Scan Characters 

SPANC Span Characters 

MATCHC Match Characters 


Variable-Length Bit Field Instructions 


EXTV Extract Field 

EXTZV Extract Zero-Extended Field 
INSV Insert Field 

CMPV Compare Field 

CMPZV Compare Zero-Extended Field 
FFS Find First Set 

FFC Find First Clear 


Table 4-3 (Cont.) 
Instruction Set Summary 


index Instruction 


Loop and Case Branch 


INDEX 


Queue Instructions 


Compute Index 


INSQUE Insert Entry in Queue 

INSQHI Insert Entry into Queue at Head, Interlocked 

INSQTI Insert Entry into Queue at Tail, Interlocked 

REMQUE Remove Entry from Queue 

REMQHI Remove Entry from Queue at Head, 
Interlocked 

REMOQTI Remove Entry from Queue at Tail, 


interlocked 


Address Manipulation Instructions 


MOVA_ 
PUSHA_ 


Move Address (B,W,L=F,Q=D=G,0=h) 
Push Address (B,W,L=F,Q=D=G,0O=H) 
on Stack 


General Register Manipulation Instructions 


PUSHL Push Longword on Stack 

PUSHR Push Registers on Stack 

POPR Pop Registers from Stack 

MOVPSL Move from Processor Status Longword 
BISPSW Bit Set Processor Status Word 
BICPSW Bit Clear Processor Status Word 


Unconditional Branch and Jump Instructions 


BR_ 
JMP 


Branch with (B, W) Displacement 
Jump 


Branch on Condition Code 


BLSS Less Than 

BLSSU Less than Unsigned 

BLEQ Less than or Equal 

BLEQU Less than or Equal Unsigned 
BEQL Equal 

(BEQLU) (Equal Unsigned) 

BNEQ Not Equal 

(BNEQU) (Not Equal Unsigned) 

BGTR Greater than 

BGTRU Greater than Unsigned 
BGEQ Greater than or Equal 
BGEQU Greater than or Equal Unsigned 
(BCC) (Carry Cleared) 

(BCS) (Carry Set) 

BVS Overflow Set 

BVC Overflow Clear 


Branch on Bit 


BLB_ Branch on Low Bit (Set, Clear) 

BB_ Branch on Bit (Set, Clear) 

BBS_ Branch on Bit Set and (Set, Clear) Bit 
BBC_ Branch on Bit Clear and (Set, Clear) Bit 
BBSSI Branch on Bit Set and Set Bit Interlocked 
BBCCI Branch on Bit Clear and Clear Bit 


interlocked 


ACB_ Add, Compare and Branch (B,W,L,F,D,G,H) 
AOBLEQ Add One and Branch Less Than or Equal 
AOBLSS Add One and Branch Less Than 
SOBGEQ Subtract One and Branch Greater 

Than or Equal 
SOBGTR Subtract One and Branch Greater Than 
CASE_ Case on (B,W,L) 


Subroutine Call and Return Instructions 


BSB_ Branch to Subroutine with (B,W) 
Displacement 

JSB Jump to Subroutine 

RSB Return from Subroutine 


Procedure Call and Return Instructions 


CALLG Call Procedure with General Argument List 
CALLS Call Procedure with Stack Argument List 
RET Return from Procedure 


Protected Procedure Call and Return Instructions 


CHM_ Change Mode to (Kernel, Executive, 
Supervisor, User) 

REI Return from Exception or Interrupt 

PROBER Probe Read 

PROBEW Probe Write 


Privileged Processor Register Control Instructions 


SVPCTX Save Process Context 
LDPCTX Load Process Context 

MTPR Move to Process Register 
MFPR Move from Processor Register 


Special Function Instructions 


CRC Cyclic Redundancy Check 
BPT Breakpoint Fault 

XFC Extended Function Call 
NOP No Operation 

HALT Halt 


* The underscore following the instruction name implies that the 
instruction will operate upon any data type contained in the 


parentheses following that instruction. 


**B = byte 

W = word 

L = longword 

Q = quadword 
O = octaword 

F = F_floating 
D = D_floating 
G = G_floating 
H = H_floating 


Instructions that operate on G, H, and O formats are only avail- 
able on VAX family processors equipped with the extended 
range floating point option. 


The arithmetic instructions include both two-operand and 
three-operand forms that eliminate the need to move data 
to and from temporary operands. The two-operand in- 
structions store the result in one of the two operands, as in 
“Set A equal to A plus B.” The three-operand instructions 
effectively implement the high-level language statements 
in which two different variables are used to calculate a 
third, such as “Set C equal to A plus B.” The three-oper- 
and instructions are applicable to both integer and float- 
ing-point data, and equivalent instructions exist for 
packed-decimal data. 


To illustrate the instruction set and addressing modes, 
consider the FORTRAN language statement: 

A(l) = Bil) * C(I) 

where A, B, and C are statically allocated REAL*4 arrays 


and | is INTEGER*4. A code sequence that performs this 
operation is: 


MOVL |,RO ;Move the longword | 
‘to a register 
MULF3 B[RO],C[RO],A[RO] ;3-operand floating 


smultiply 
The same code applies if A, B, and C are REAL’8, IN- 
TEGER*4, INTEGER*%2, or even INTEGER*1 data types; the 
MULF3 instruction is simply changed to MULD3, MULLS3, 
MULWS, or MULBS, respectively. 


If arrays A, B, and C are dynamically allocated arrays, the 
code sequence could be: 

MOVL 1,RO 

MULF3 Bdisp(FP)[R0],Cdisp(FP)[RO],Adisp(FP)[RO] 


If A, B, and C are arguments to a procedure, the code 
could be: 


MOVL |,RO 
MULF3 @Bargptr(AP)[RO],@Cargptr(AP)[RO], 
‘;@Aargptr[RO] 


In fact, the locations of A, B, and C can be arbitrarily se- 
lected. For example, combining the above, if A is statically 
allocated, B dynamically allocated, and C an argument, 
then the code sequence could be: 


MOVL |,RO 
MULF3 Bdisp(FP)[RO],@Cargptr(AP)[RO],A[RO] 


Some of the arithmetic instructions are used for extending 
the accuracy of repeated computations. The Extended 
Multiply (EMUL) instruction takes longword integer argu- 
ments and produces a quadword result. The instruction ef- 
fectively implements a high-level language statement such 
as “Set D equal to (A times B) plus C.” The Extended Di- 
vide (EDIV) instruction divides a quadword integer by a 
longword and produces a longword quotient and a long- 
word remainder. 


The Extended Modulus (EMOD) instruction multiplies a 
floating-point number with an extended precision floating- 
point number (extended by eight bits for F_floating and 
D_floating for an effective nine or 19 digits of accuracy) 
and returns the integer portion and the fractional portion 
separately. This instruction is particularly useful for the re- 
duction of the argument of trigonometric and exponential 
functions to a standard interval. 


The Polynomial Evaluation (POLY) instructions evaluate a 


polynomial from a table of coefficients, using Horner's 
method. This instruction is used extensively in the high- 
level languages’ math library for operations such as sine 
and cosine. 


Packed-Decimal Instructions 

Many of the operations for integer and floating-point data 
also apply to packed-decimal strings. They include: 

Move Packed (MOVP) for copying a packed-decimal 
string from one location to another and Arithmetic Shift 
Packed (ASHP) for scaling a packed-decimal up or 
down by a given power of ten while moving it, and then 
optionally rounding the value. 

Compare Packed (CMPP) for comparing two packed- 
decimal strings. Compare Packed has two variations: a 
three-operand (CMPP%3) instruction for strings of equal 
length, and a four-operand instruction (CMPP4) for 
strings of differing lengths. 


Convert Instructions, including Convert Long to Packed 
(CVTLP), Convert Packed to Long (CVTPL), Convert 
Packed to Numeric with Trailing sign (CVTPT), Convert 
Numeric with Trailing sign to Packed (CVTTP), Convert 
Packed to Numeric with Separate overpunched sign 
(CVTPS), and Convert Numeric with Separate over- 
punched sign to Packed (CVTSP). These instructions 
enable the conversion of our packed-decimal format to 
commonly used numeric formats. Numeric with trailing 
sign allows various sign encodings including zoned and 
overpunched. 


e Add Packed (ADDP) and Subtract Packed (SUBP) for 
adding or subtracting two packed-decimal strings, with 
the option of replacing the addend or subtrahend with 
the result (ADDP4 and SUBP4), or storing the result ina 
third string (ADDP6 or SUBP6). 


Multiply Packed (MULP) and Divide Packed (DIVP) for 
multiplying or dividing two packed-decimal strings and 
storing the result in a third string. 


In addition, the packed-decimal instructions include a spe- 
cial packed-decimal-string to character-string conversion 
instruction that provides output formatting: the Edit in- 
struction. 


Edit Instruction 

The Edit Packed to Character String (EDITPC) instruction 
supplies formatted numeric output functions. The instruc- 
tion converts a given packed-decimal string into a 
character string, using selected pattern operators. The 
pattern operators enable the creation of numeric output 
fields with any of the following characteristics: 

Leading zero fill 

Leading zero protection 

Leading asterisk fill protection 

e A floating sign 

e A floating currency symbol 

Special sign representations 

Insertion characters 


Blank when zero 


Character String Instructions 

The character string instructions operate on strings of 
bytes. They include: 

® Move string instructions, with translation options 

® String compare instructions 

® Single character search instructions 

® Substring search instructions 


There are two basic forms of Move instructions for charac- 
ter strings. The Move Character instructions (MOVC3 and 
MOVC5) simply copy character strings from one location 
to another. They are optimized for block-transfer opera- 
tions. The five-operand variation provides for a fill charac- 
ter (user-supplied) that the instruction uses to pad out the 
destination location to a given size. 


The Move Translated Characters (MOVTC) and Move 
Translated Until Character (MOVTUC) instructions actually 
create new character strings. The user supplies a string, 
which the instruction uses as a list of offsets, into a transla- 
tion table. The instruction selects characters from the table 
in the order that the offset list points to the table. The 
MOVTC instruction allows the user to supply a fill charac- 
ter that the instruction uses to pad out the resultant string 
to a given size with an arbitrary character. The MOVTUC 
instruction allows the user to supply any number of escape 
characters. When the next offset points to an escape char- 
acter in the table, translation stops. 


The Compare Characters (CMPC) instructions provide 
character-by-character byte string compares. CMPC has a 
three-operand form and a five-operand form. Both in- 
structions compare two strings from beginning to end, in- 
forming the user when they reach the first character that is 
different between the strings or when they get to the end of 
either string. The five-operand variation provides for a fill 
character that it uses to effectively pad out a string, when 
comparing it with a longer one. 


The Locate Character (LOCC) and Skip Character (SKPC) 
instructions are search instructions for single characters 
within a string. LOCC searches a given string for a charac- 
ter that matches the search character supplied by the 
user. This is useful, for example, when searching for the 
delimiter at the end of a variable-length string. SKPC, on 
the other hand, finds the first character in the string that is 
different from the search character supplied. This is useful 
for skipping through fill characters at the end of a field to 
find the beginning of the next field. 


The Match Characters (MATCHC) instruction is similar to 
the Locate Character instruction, but it locates multiple- 
character substrings. MATCHC searches a string for the 
first occurrence of a substring supplied by the user. 


The Span Characters (SPANC) and Scan Characters 
(SCANC) instructions are search instructions that look for 
members of character classes. For these instructions the 
user supplies a character-string, a mask, and the address 
of a 256-byte table of character type definitions. For each 
character in the given string, the instruction looks up the 
type code in the table for that character, and then AND the 
given mask with the character’s type code. SPANC finds 
the first character in the string that is of the type indicated 
by its mask. SCANC finds the first character in the string 
that is of any type other the one indicated by its mask. 
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The Index Instruction 

The Index instruction (INDEX) calculates an index for an 
array of fixed-length data types (integer and floating) and 
for arrays of bit fields, character strings, and decimal 
Strings. It accepts as arguments; a subscript, lower and 
upper subscript bounds, an array element size, a given in- 
dex, and a destination for the calculated index. It incorpo- 
rates range checking within the calculation for high-level 
languages, using subscript bounds, and it allows index 
calculation optimization by removing invariant expres- 
sions. 


The COBOL statements: 


01 A-ARRAY 

02 APICX(10) OCCURS 15 TIMES. 
B PIC X(10). 

MOVE A(l) TO B. 


01 


are equivalent to: 


INDEX |, #1, #15, #10, #0, RO; 1 less than or equal | 

; | less than or equal 15 
°(0+1)* 10is 

- stored in RO 

MOVCS3 #10, A—10[R0],B 


The FORTRAN statements: 


INTEGER*4 A(L1:U1, L2:U2), I, J 
A(\,J) = 1 


are equivalent to: 
INDEX J, #L2, #U2, #M1, #0, RO 


INDEX |, #L1, #U1, #1, RO, RO 
MOVL #1, A—a[RO] 


;M1=U1-L1 


a = ((L2*M1)+L1)*4 


Variabie-Length Bit-Field Instructions 

The bit-field instructions enable the user to define, access, 
and modify those fields having user-specified size and lo- 
cation. Location is determined from a base address or a 
register and a signed bit offset. If the field is in memory, 
the offset can reach bits located up to 2°' bits (approxi- 
mately 256 million bytes) away in either direction. If the 
field is in a register, the offset can be large as 31. Fields of 
arbitrary lengths (0 to 32 bits) can be used for storing data 
structure header information compactly, for status codes, 
or for creating user data types. The field instructions en- 
able manipulation of fields easily. 


The Insert Field and Extract Field instructions store data in 
and retrieve data from fields. Insert Field (INSV) stores 
data in a field by taking a specified number of bits of a 
longword (starting from the low-order bit) and writing them 
into a field, which can start at any bit relative to a given 
base address. The Extract Field instruction retrieves data 
from a field by copying the bit field and storing it in the low- 
order bits of a longword. The field can either be signed 
(EXTV) or unsigned (EXTZV). 


The Compare Field and Find First instructions enable the 
user to test the contents of a field. Compare Field extracts 
a field and then compares it with a given longword. The 


field can be interpreted as signed (CMPV) or as unsigned 
(CMPZV). The Find First instructions locate the first bit in a 
field that is clear (FFC) or set (FFS), scanning from low-or- 
der bits to high-order bits. These instructions are particu- 
larly useful for scanning a status control longword. For ex- 
ample, the longword could represent a set of queues 
processed in order by priority 0 (high) to 31 (low). Each set 
bit represents an active queue. The Find First Set instruc- 
tion quickly returns the highest-priority queue that is ac- 
tive. Together with the SKPC instructions, the Find First in- 
structions are also useful for scanning an allocation table 
(bit map) of arbitrary length. 


Queue Instructions 

The processor has six instructions that allow easy con- 
struction and maintenance of queue data structures. 
Queues manipulated using the queue instructions are cir- 
cular doubly linked lists of data items. 


The first longword of a queue entry contains the forward 
pointer to the next entry in the queue, and the next long- 
word contains the backward pointer to the preceding entry 
in the queue. 


Two types of queues are provided: absolute and self-rela- 
tive. Absolute queues use pointers that are virtual 
addresses, whereas self-relative queues use pointers that 
are relative displacements. 


Two instructions are provided for manipulating absolute 
queues: INSQUE, and REMQUE. INSQUE inserts an entry 
specified by an entry operand into the queue, following the 
entry specified by the predecessor operand. REMQUE re- 
moves the entry specified by the entry operand. Queue en- 
tries can be on arbitrary byte boundaries. Both INSQUE 
and REMQUE are implemented as noninterruptible in- 
structions. 


Four operations can be performed on self-relative queues: 
insert at head (INSQHI), remove from head (REMQH1), in- 
sert at tail (INSQTI), and remove from tail (REMQTI). Furth- 
ermore, these operations are interlocked to allow 
cooperating processes in a multiprocessor system to ac- 
cess a shared queue without additional synchronization. 
Queue entries must be quadword-aligned. 


Address Manipulation Instructions 

Because the processor offers a variety of addressing 

modes enabling access to data structures easily via base 

addresses and indices in registers, addresses are often 

manipulated. The processor provides two instructions that 

enable an address to be fetched without actually access- 

ing the data at that location: 

® The Move Address (MOVA) instruction, which stores the 
address of a byte, word, longword (and floating), or 
quadword (and double-floating) datum in a specified 
register or location in memory. 

® The Push Address (PUSHA) instruction, which stores 
the address of a byte, word, longword (and floating), or 
quadword (and double-floating) datum on the stack. 


The Push Address instruction is useful for computing an 
address to be passed to a called subroutine or procedure. 
The Move Address is useful for loading a base register and 
performing runtime position-independent address com- 
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putation. It has some interesting uses because it is effec- 
tively an ADD instruction: 


MOVAB disp(R1)[R2],X  ;setsX=R1+R2+displacement 


; (two adds in one instruction) 
MOVA_disp(Rn)[Rn],Rn_ ; multiplies Rn by 3 
‘(for MOVAW), 
;5 (for MOVAL), 
; or 9 (for MOVAQ) 
‘and adds displacement to it. 


General Register Manipulation Instructions 

The general register manipulation instructions enable any 
user program to save or load the general purpose regis- 
ters in one operation, examine the Processor Status 
Longword, and set or clear status bits in the Processor 
Status Word. (Processor register control instructions pri- 
marily used by operating system software are covered la- 
ter.) 


The Push Longword (PUSHL) instruction pushes a long- 
word on the stack. This instruction is the same as a Move 
Longword using the Stack Pointer in register-deferred 
mode, but is a byte shorter. It is a consistent and conven- 
ient way to move data to the stack. 


The Push Registers (PUSHR) instruction pushes a set of 
registers on the stack in one operation. The user supplies 
a mask word in which each set bit (0-14) represents a 
register (RO-R14) to be saved on the stack. (The only gen- 
eral register that cannot be saved using this instruction is 
R15, the Program Counter.) Pop Registers (POPR) reverse 
the operation, loading each register from successive long- 
words on the stack according to the given mask word. The 
PUSHR and POPR instructions replace the need to write a 
sequence of Move instructions to save and restore regis- 
ters upon entry and exit from a subroutine. 


The Move from Processor Status Longword (MOVPSL) 
instruction allows examination of the contents of the proc- 
essor’s status register by loading its contents into a speci- 
fied location. The Bit Set (BISPSW) and Bit Clear 
(BICPSW) Processor Status Word instructions enable the 
user to set or clear the PSW condition codes and trap en- 
able bits. The mask bits represent the bits to be set or 
cleared. 


Branch, Jump, and Case Instructions 

The two basic types of control-transfer instructions are 
branch and jump instructions. Both branch and jump load 
new addresses in the Program Counter. With branch in- 
structions, the user-supplied displacement (offset) is 
added to the current contents of the Program Counter to 
obtain the new address. The jump instructions allow the 
user-specified address to be loaded, using one of the nor- 
mal addressing modes. 


Because most transfers are to locations relatively close to 
the current instruction, and because branch instructions 
are more efficient than jump instructions, the processor 
offers a variety of branch instructions to choose from. 
There are two unconditional branch instructions and many 
conditional branch instructions. 


The unconditional branch instructions allow specification 
of either a byte-sized (BRB) or a word-sized displacement 


(BRW), thereby permitting displacements as far away from 
the current location as 32,767 bytes in either direction. The 
Jump instruction (JMP) should be used for transfer of con- 
trol to locations greater in displacement than 32,767 bytes. 


Most conditional branches allow only byte displacements, 
although some of the more powerful, such as the Add 
Compare and Branch instruction, allow word displace- 
ments. Conditional branch instructions include: 

Branch on bit instructions. 


e Set and clear bit instructions with a branch if it is already 
set or cleared. 


Loop instructions that increment or decrement a coun- 
ter, compare it with a limit value, and branch on a rela- 
tional condition. 

Computed branch instruction in which a branch can 


take place to one of several locations, depending on a 
computed value. 


The Branch on Condition (B) instructions enable transfer 

of control to another location, depending on the status of 

one or more of the condition codes in the Processor Status 

Word (PSW). There are three groups of Branch on Condi- 

tion instructions: 

e The signed relational branches, which are used to test 
the outcome of instructions operating on integer and 
field data types being treated as signed integers, float- 
ing-point data types, and decimal strings. 


The unsigned relational branches, which are used to test 
the outcome of instructions operating on integer and 
field data types being treated as unsigned integers, 
character strings, and addresses. 


The overflow and carry test branches, which are used 
for checking overflow when traps are not enabled, for 
multiprecision arithmetic, and for the results of special 
instructions. 


The instruction mnemonics clearly indicate the choice 
between a signed and unsigned integer data type interpre- 
tation for relational testing. The relational tests determine 
if the result of the previous operation is less than, less than 
or equal, equal, not equal, greater than or equal, or greater 
than zero. For example, the Branch on Less than or Equal 
Unsigned (BLEQU) instruction branches if either the Carry 
or Zero bit is set. The Branch on Greater Than (BGTR) in- 
struction branches if neither the Negative nor the Zero bit 
is set. 


General purpose Branch on Bit instructions similar to 
Branch on Condition also exist. The Branch on Low Bit Set 
(BLBS) and Branch on Low Bit Clear (BLBC) instructions 
test bit O of an operand; this is useful for testing Boolean 
values. The Branch on Bit Set (BBS) and Branch on Bit 
Clear (BBC) instructions test any selected bit. 


There are special kinds of Branch on Bit instructions that 
are actually bit set or clear instructions. The Branch on Bit 
Set and Set (BBSS) is an example. The instruction 
branches if the indicated bit is set; otherwise it falls 
through. In either case, the instruction sets the given bit. 
The BBSS instruction can thus be thought of as a Bit Set 
instruction, with a branch side effect if the bit was already 
set. There are four permutations: 

e Branch on Bit Set and Set (BBSS) 


e Branch on Bit Clear and Clear (BBCC) 
e Branch on Bit Set and Clear (BBSC) 
e Branch on Bit Clear and Set (BBCS) 


These instructions are particularly useful for keeping track 
of procedure completion or initialization and for signaling 
the completion or initialization of a procedure to a cooper- 
ating process. In addition, there are two Branch on Bit In- 
terlocked instructions that provide control variable protec- 
tion: 

e Branch on Bit Set and Set Interlocked (BBSSI) 

e Branch on Bit Clear and Clear Interlocked (BBCCIl) 


The memory interconnect bus provides a memory 
interlock on these instructions. No other BBSSI or BBCCI 
operation can interrupt these instructions to gain access to 
the byte containing the control variable between the test- 
ing of the bit and the setting or clearing of the bit. 


The processor offers three types of branch instructions 
that can be used to write efficient loops. The first type pro- 
vides the basic subtract-one-and-branch loop. A counter 
variable (user-supplied) is decremented each time the 
loop is executed. In the Subtract One and Branch Greater 
Than (SOBGTR) instruction, the loop repeats until the 
counter equals zero. In the Subtract One and Branch 
Greater Than or Equal (SOBGEQ) instruction, the loop re- 
peats until the counter becomes negative. 


The counterpart to Subtract One and Branch is Add One 
and Branch. A counter and a limit must be supplied by the 
user. The counter is incremented at the end of the loop. In 
the Add One and Branch Less Than (AOBLSS) instruction, 
the loop repeats until the counter equals the user-defined 
limit. In the Add One and Branch Less Than or Equal (AO- 
BLEQ) instruction, the loop repeats until the counter 
exceeds the user defined limit. 


The third type of loop instruction efficiently implements the 
FORTRAN language DO statement and the BASIC lan- 
guage FOR statement: Add Compare and Branch (ACB). 
In this case, the user must supply a limit, a counter, and a 
step value. For each execution of the loop, the instruction 
adds the step value to the counter and compares the 
counter to the limit. The sign of the step value determines 
the logical relation of the comparison: the instruction loops 
on a less-than-or-equal comparison if the step value is po- 
sitive, on a greater-than-or-equal comparison if the step 
value is negative. 


The processor provides a branch instruction that imple- 
ments higher-level language computed GO TO state- 
ments: the CASE instruction. To execute the CASE in- 
struction, the user must supply a list of displacements that 
generate different branch addresses indexed by the value 
obtained as a selector. The branch falls through if the 
selector does not fall within the limits of the list. 


Subroutine Branch, Jump, and Return Instructions 

Two special types of branch and jump instruction are pro- 
vided for calling subroutines: the Branch to Subroutine 
(BSB) and Jump to Subroutine (JSB) instructions. Both 
BSB and JSB instructions save the contents of the Pro- 
gram Counter on the stack before loading the Program 
Counter with the new address. With Branch to Subroutine, 
the user supplies either a byte (BSBB) or word (BSBW) 


displacement. With Jump to Subroutine, regular address- 
ing is used. 

The subroutine call instructions are complemented by the 
Return from Subroutine (RSB) instruction. RSB pops the 
first longword off the stack and loads it into the Program 
Counter. Since the Branch to Subroutine instruction is ei- 
ther two or three bytes long, and since the Return from 
Subroutine instruction is one byte long, it is possible to 
write extremely efficient programs using subroutines. 


Procedure Call and Return Instructions 

Procedures are general purpose routines that use argu- 
ment lists passed automatically by the processor. The pro- 
cedure Call instructions enable language processors and 
the operating system to provide a standard calling inter- 
face. They: 

e Save all the registers that the procedure uses — and 

only those registers — before entering the procedure. 


e Pass an argument list to a procedure. 


e Maintain the Stack, Frame, and Argument Pointer regis- 
ters. 


@ Initialize the arithmetic trap enables to a given state. 


When issuing a Call procedure instruction, the address of 
the procedure being called must be included. The first 
word of a procedure contains an entry mask that is used in 
the same way as the entry mask defined for the Push 
Registers instruction. Each set bit of the 12 low-order bits 
in the word represents one of the general registers (RO 
through R11) that the procedure uses. The Call instruction 
examines this word and saves the indicated registers on 
the stack. In addition, the Call instruction also automati- 
cally saves the contents of the Frame Pointer, Argument 
Pointer, and Program Counter registers. This is an ex- 
tremely efficient way to ensure that registers are saved 
across procedure calls. No general register is saved that 
does not have to be saved. 


The Call Procedure with General Argument List (CALLG) 
instruction accepts the address of an argument list and 
passes the address to the procedure in the Argument 
Pointer register. The Call Procedure with Stack Argument 
List (CALLS) passes the argument list (placed on the stack 
by the user) by loading the Argument Pointer register with 
its stack address. 

When a procedure completes execution, it issues the Re- 
turn from Procedure instruction (RET). Return uses the 
Frame Pointer register to find the saved registers that it re- 
stores and to clean up any data left on the stack — includ- 
ing nested routine linkages. A procedure can return values 
using the argument list or other registers. 


Miscellaneous Special Purpose Instructions 

The processor has a number of special purpose instruc- 
tions. They include: 

Cyclic Redundancy Check (CRC) 

Breakpoint Fault (BPT) 

Extended Function Call (XFC) 

No Operation (NOP) 

Halt 


The Cyclic Redundancy Check (CRC) instruction 
calculates a cyclic redundancy check for a given string us- 


ing any CRC polynomial up to 32 bits long. The user sup- 
plies the string for which the CRC is to be performed, and 
a table for the CRC function. The operating system library 
includes tables for standard CRC functions, such as CRC- 
16. 


The Breakpoint Fault (BPT) instruction makes the proces- 
sor execute the kernel-mode condition handler associated 
with the Breakpoint Fault exception vector. BPT is used by 
the operating system debugging utilities, but can also be 
used by any process that sets up a Breakpoint Fault 
condition handler. 


The Extended Function Call (XFC) instruction allows es- 
Capes to customer-defined instructions in writable control 
store. 


The NOP instruction is useful for debugging. 


The HALT instruction is a privileged instruction issued only 
by the operating system to halt the processor when bring- 
ing the system down by operator request. 


COMPATIBILITY MODE 

Under control of the operating system, the processor can 
execute PDP-11 instruction streams within the context of 
any process. When executing in compatibility mode, the 
processor interprets the instruction stream executing in 
the context of the current process as a subset of the PDP- 
11 instruction set. 


In general, compatibility mode enables the operating sys- 
tem to provide an environment for executing most user- 
mode programs written for a PDP-11, except stand-alone 
software. The processor expects all compatibility-mode 
software to rely on the services of the native operating sys- 
tem for I/O processing, interrupt and exception handling, 
and memory management. There are some restrictions, 
however, on the environment that the native operating sys- 
tem can provide a PDP-11 program. For example, the 
PDP-11 memory management instructions, Move 
To/From Previous Instruction/Data Space can not be sim- 
ulated by the operating system since they do not trap to 
native-mode software. 


PDP-11 Program Environment 

PDP-11 addresses are 16-bit byte addresses. There is a 
one-to-one correspondence between compatibility mode 
virtual addresses and the first 64 Kbytes of virtual address 
space available to native-mode processes. As in the PDP- 
11, a compatibility-mode program is restricted to refer- 
encing only these addresses. It is possible for the operat- 
ing system to provide most of the PDP-11 memory man- 
agement mechanisms. For example, compatibility mode 
automatically supports PDP-11 memory-segment protec- 
tion, but in 512-byte (rather than 64-byte segments). 


All of the PDP-11 general registers and addressing modes 
are available in compatibility mode. Compatibility-mode 
registers RO through Ré6 are the low-order 16 bits of native- 
mode registers RO through R6. Compatibility mode R7 (the 
Program Counter) is the low-order bits of native-mode 
register 15 (the Program Counter). Native-mode registers 
8 through 14 are not affected by compatibility mode. Note 
that the compatibility-mode register R6 acts as the Stack 
Pointer for program-local temporary data storage, but that 


the program-local stack is allocated address space in the 
program region, not in the control region. 


A subset of the PDP-11 Processor Status Word is defined 
for compatibility mode. Only the condition codes and the 
trace trap bit are relevant for the PDP-11 instruction 
stream. 


All interrupts and exceptions that occur when the proces- 
sor is executing in compatibility mode cause the processor 
to enter native mode. As in native mode, it is the operating 
system’s responsibility to handle interrupts and excep- 
tions. There are a few types of exceptions that apply only 
to compatibility mode. They include illegal instruction ex- 
ceptions and odd-address traps. 


PDP-11 Instruction Set 

The compatibility mode instruction set is the same as that 

of the PDP-11, with the following exceptions: 

® The privileged instructions (HALT, WAIT, RESET, SPL, 
and MARK) are illegal. 

® The trap instructions (BPT, IOT EMT, and TRAP) cause 
the processor to enter native mode, then, either the trap 
can be serviced or the instruction simulated. 


® The Move From/To Previous Instruction/Data space 
instructions (MFPI, MTPI, MFPD, and MTPD) execute 
exactly as they would on a PDP-11 in user mode with in- 
struction and data space overmapped. They ignore the 
previous access level and act as PUSH and POP instruc- 
tions referencing the current stack. 


® PDP-11 floating-point instructions are emulated through 
software. 


All other instructions execute as they would on a PDP- 
11/70 processor running in user mode. 


PROCESSING CONCEPTS FOR 

SYSTEM PROGRAMMING 

The processor is specifically designed to support a high- 
performance multiprogramming environment. The chief 
advantage of a multiprogramming system is its ability to 
get the most out of a computer that is being used for sev- 
eral different purposes concurrently. For example, mul- 
tiprogramming enables the simultaneous execution of two 
or more application systems, such as process control and 
order entry. It is also possible to execute several applica- 
tion systems while simultaneously developing application 
programs. The characteristics of the hardware systems 
that support multiprogramming are: 

® Rapid context switching 

® Priority dispatching 

® Virtual addressing and memory management 


As a multiprogramming system, VAX not only provides the 
ability to share the processor among processes, but also 
protects processes from one another while enabling them 
to communicate with each other and share code and data. 


Context Switching 

In a multiprogramming environment, several individual 
streams of code can be ready to execute at any one time. 
Instead of allowing each stream to execute to completion 
serially (as in a batch-only system), the operating system 
can intervene and switch between the streams of code that 
are ready to execute. 
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To support multiprogramming for a high-performance 
system, the processor enables the operating system to 
switch rapidly between individual streams of code. The 
stream of code the processor is executing at any one time 
is determined by its hardware context. 


Hardware context includes the information loaded in the 
processor's registers that identifies: 

© Where the stream’s instructions and data are located 

® Which instruction to execute next 

® What the processor status is during execution 


A process is a stream of instructions and data defined bya 
hardware context. Each process has a unique identifica- 
tion in the system. The operating system switches between 
processes by requesting the processor to save one proc- 
ess hardware context and load another. Context switching 
occurs rapidly because the processor instruction set in- 
cludes save-hardware-context and load-hardware-context 
instructions. The operating system’s context-switching 
software does not have to individually save or load the 
processor registers that define the hardware context. 


The actual scheduling mechanism for arbitrating among 
processes competing for processor time is left to the oper- 
ating-system software itself, to give the system flexibility. 


Priority Dispatching 

While running in the context of one process, the processor 
executes instructions and controls data flow to and from 
peripherals and main memory. To share processor, mem- 
ory and peripheral resources among many processes, the 
processor provides two arbitration mechanisms that sup- 
port high-performance multiprogramming: exceptions 
and interrupts. Exceptions are events that occur synchro- 
nously with respect to instruction execution; interrupts are 
external events that occur asynchronously. 


The flow of execution can change at any time. The proces- 
sor distinguishes between changes in flow that are local to 
a process and those that are systemwide. Process-local 
changes occur as the result of a user software error or 
when user software calls operating-system services. Proc- 
ess-local changes in program flow are handled through 
the processor’s exception-detecting mechanism and the 
operating system's exception dispatcher. 


Systemwide changes in flow generally occur as the result 
of interrupts from devices or interrupts generated by the 
operating-system software. Interrupts are handled by the 
processor's interrupt detection mechanism and the oper- 
ating system’s interrupt service routines. (Systemwide 
changes in flow may also occur as the result of severe 
hardware errors, in which case they are handled either as 
special exceptions or high-priority interrupts.) 


Systemwide changes in flow take priority over process-lo- 
cal changes in flow. Furthermore, the processor uses a 
priority system for servicing interrupts. To arbitrate 
between all possible interrupts, each kind of interrupt is 
assigned a priority, and the processor responds to the 
highest-priority pending interrupt. For example, interrupts 
from realtime I/O devices would take precedence over in- 
terrupts from mass-storage devices, terminals, lineprin- 
ters and other less time-critical devices. 


The processor services interrupts between instructions or 
at well-defined points during the execution of long, itera- 
tive instructions. When the processor acknowledges an 
interrupt, it switches rapidly to a special systemwide con- 
text to enable the operating system to service the interrupt. 
Systemwide changes in the flow of execution are handled 
in such a way that they are totally transparent to individual 
processes. 


Virtual Addressing and Virtual Memory 

The processor’s memory management hardware enables 
the operating system to provide an execution environment 
in which users can write programs without having to know 
where the programs are loaded in physical memory and in 
which they can write programs that are too large to fit in 
the physical memory they are allocated. 


The processor provides the operating system with the abil- 
ity to provide virtual addressing. A virtual address is a 32- 
bit integer that a program uses to identify storage loca- 
tions in virtual memory. Virtual memory is the set of all 
physical memory locations in the system plus the set of 
disk blocks that the operating system designates as exten- 
sions to physical memory. 


A physical address is an address that the processor uses 
to identify physical-memory storage locations and peri- 
pheral controller registers. It is the physical address that 
the processor sends to the memory and peripheral adap- 
tors. 


The processor must be capable of translating virtual 
addresses provided by the executing program into the 
physical addresses that are recognized by the memory 
and peripherals. To provide virtual to physical address 
mapping, the processor has address mapping registers 
that are controlled by the operating system and an integra- 
ted address translation buffer. 


The mapping registers enable the operating system to re- 
locate programs in physical memory, to protect programs 
from each other, and to share instructions and data 
between programs transparently or at the programs’ re- 
quest. The address-translation buffer ensures that the 
virtual address to physical-address translation takes place 
rapidly. 


SYSTEM PROGRAMMING ENVIRONMENT 

Within the context of one process, user-level software con- 
trols the execution using the instruction sets, the general 
registers, and the Processor Status Word. Within the mul- 
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tiprogramming environment, the operating system con- 
trols the system’s execution using a set of special 
instructions, the Processor Status Longword, and the in- 
ternal processor registers. 


Processor Status Longword 

A processor register called the Processor Status Long- 
word (PSL) determines the execution state of the proces- 
sor at any time. The low-order 16 bits of the Processor 
Status Longword is the Processor Status Word available to 
the user process. The high-order 16 bits provide privi- 
leged control of the system. Figure 4-4 illustrates the Proc- 
essor Status Longword. 


The fields can be grouped together by functions that con- 
trol: 


© The instruction set the processor is executing. 
® The access mode of the current instruction. 
e Interrupt processing. 


The instruction set the processor executes is controlled by 
the compatibility-mode bit in the Processor Status 
Longword. This bit is normally set or cleared by the oper- 
ating system. For further information on compatibility 
mode, refer to the Operating System section. 


The following paragraphs discuss access modes, the na- 
tive instructions primarily used by the operating system, 
memory management, and interrupt processing. 


Processor Access Modes 

In a high-performance multiprogramming system, the 

processor must provide the basis for protection and shar- 

ing among the processes competing for the system’s re- 

sources. The basis for protection in this system is the 

processor's access mode. The access mode in which the 

processor executes determines: 

@ Instruction execution privileges: which instructions the 
processor will execute. 

e Memory access privileges: which locations in memory 
the current instruction can access. 


At any one time, the processor is either executing code in 
the context of a particular process or it is executing in the 
systemwide interrupt service context. In the context of a 
process, the processor recognizes four access modes: 
kernel, executive, supervisor, and user. Kernel is the most 
privileged mode and user the least privileged. 
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The processor spends most of its time executing in user 
mode in the context of one process or another. When user 
software needs the services of the operating system — 
whether for acquisition of a resource, for I/O processing, 
or for information — it calls those services. 


The processor executes those services in the same access 
mode or in one of the more privileged access modes 
within the context of that process. That is, all four access 
modes exist within the same virtual address space. Each 
access mode has its own stack in the control region of per- 
process space, and therefore, each process has four 
stacks: one for each access mode. Note that this makes it 
easy for the operating system to context-switch a process, 
even when it is executing an operating-system service pro- 
cedure. 


In any mode except kernel, the processor will not execute 
the instructions that: 

e Halt the processor. 

e Load and save process context. 


e Access the internal processor registers that control 
memory management, interrupt processing, the proces- 
sor console, or the processor clock. 


These instructions are privileged instructions that are gen- 
erally reserved to the operating system. 


In any mode, the processor will not allow the current in- 
struction to access memory unless the mode is privileged 
to do so. The ability to execute code in one of the more 
privileged modes is granted by the system manager and 
controlled by the operating system. The memory protec- 
tion the privilege affords is enforced by the processor. In 
general, code executing in one mode can protect itself and 
any portion of its data structures from read and/or write 
access by code executing in any less privileged mode. For 
example, code executing in executive mode can protect its 
data structures from code executing in supervisor or user 
mode. Code executing in supervisor mode can protect its 
data structures from access by code executing in user 
mode. This memory protection mechanism provides the 
basis for system data structure integrity. 


Protected and Privileged Instructions 

The processor provides three types of instructions that en- 
able user mode software to obtain operating system ser- 
vices without jeopardizing the integrity of the system. They 
include: 

e The Change Mode instructions 

e The PROBE instructions 


e The Return from Exception or Interrupt instruction 


User mode software can obtain privileged services by call- 
ing operating-system service procedures with a standard 
CALL instruction. The operating system’s service 
dispatcher issues an appropriate change-mode instruc- 
tion before actually entering the procedure. Change mode 
allows access-mode transitions to take place from one 
mode to the same or more privileged mode only. When the 
mode transition takes place, the previous mode is saved in 
the Previous Mode field of the Processor Status Long- 
word, allowing the more privileged code to determine the 
privilege of its caller. 
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A Change-mode instruction is simply a special trap in- 
struction that can be thought of as an operating system 
service call instruction. User mode software can explicitly 
issue change-mode instructions, but since the operating 
system receives the trap, nonprivileged users can not write 
any code to execute in any of the privileged access modes. 
User-mode software can include a condition handler for 
change mode to user traps, however, and this instruction 
is useful for providing general purpose services for user- 
mode software. The system manager ultimately grants the 
privilege to write any code that handles change mode 
traps to more privileged access modes. 


For service procedures written to execute in privileged ac- 
cess modes (kernel, executive, and supervisor), the proc- 
essor provides address-access privilege-validation in- 
structions. The PROBE instructions enable a procedure to 
check the read (PROBER) and write (PROBEW) access 
protection of pages in memory against the privileges of the 
caller that requested access to a particular location. This 
enables the operating system to provide services that exe- 
cute in privileged modes to less privileged callers and still 
prevent the caller from accessing protected areas of mem- 
ory. 

The operating system's privileged service procedures and 
interrupt and exception service routines exit by using the 
Return from Exception or Interrupt (REI) instruction. REI is 
the only way in which the privilege of the processor’s ac- 
cess mode can be decreased. Like the procedure and 
subroutine return instructions, REI restores the Program 
Counter and the processor state to resume the process at 
the point where it was interrupted. 


REI performs special services, however, that normal return 
instructions do not. For example, REI checks to see if any 
asynchronous system traps have been queued for the cur- 
rently executing process while the interrupt or exception 
service routine was executing and also ensures that the 
process will receive them. Furthermore, REI checks to en- 
sure that the mode to which it is returning control is the 
same as or less privileged than the mode in which the 
processor was executing when the exception or interrupt 
occurred. Thus REI is available to all software, including 
user-written trap-handling routines, but a program cannot 
increase its privilege by altering the processor state to be 
restored. 


When the operating system schedules a context-switching 
operation, the context-switching procedure uses the Save 
Process Context (SVPCTX) and Load Process Context 
(LDPCTX) instructions to save the current process context 
and load another. The operating system’s context-switch- 
ing procedure identifies the location of the hardware con- 
text to be loaded by updating an internal processor regis- 
ter. 


Internal processor registers not only include those that 
identify the process currently executing, but also include 
the memory management and other registers, such as the 
console and clock control registers. The Move to Proces- 
sor Register (MTPR) and Move from Processor Register 
(MFPR) instructions are the only instructions that can ex- 
plicitly access the internal processor registers. MTPR and 
MFPR are privileged instructions that can be issued only in 
kernel mode. 
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Virtual and Physical Address Space 


Memory Management 

The processor is responsible for enforcing memory pro- 
tection between access modes. Memory protection, how- 
ever, is only a part of the processor’s memory 
management function. In particular, the memory manage- 
ment hardware enables the operating system to provide 
an extremely flexible and efficient virtual memory pro- 
gramming environment. Virtual and physical address- 
space definitions provide the basis for the virtual memory 
available on a system. 


Virtual address space consists of all possible 32-bit ad- 
dresses that can be exchanged between a program and 
the processor to identify a byte location in physical mem- 
ory. The memory management hardware translates a 
virtual address into a physical address. A physical address 
can be up to 30 bits in length — as in the case of the VAX- 
11/780. Other processor implementations can choose 
smaller physical addresses. A physical address is the ad- 
dress exchanged between the processor and the memory 
and peripheral adaptors. Physical address space is the set 
of all possible physical addresses the processor can use to 
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express unique memory locations and peripheral control 
registers. Figure 4-5 compares the structure of the com- 
mon virtual address space with that of the VAX-11/750 and 
VAX-11/780 physical address spaces. 


On the VAX-11/780, physical address space is an array of 
addresses that can be used to represent 2°° byte locations, 
or approximately one billion bytes. Half of the addresses in 
VAX-11/780 physical address space can be used to refer 
to real memory locations and the other half can be used to 
refer to peripheral device control and data registers. The 
lowest-addressed half of physical address space is called 
memory space, and the highest-addressed half is called 
I/O space. On the VAX-11/750, physical address space is 
an array of addresses which can be used to represent 274 
byte locations, or approximately 16 million bytes. The first 
15M bytes are dedicated to physical memory addresses 
while the last 1M byte is dedicated to I/O space. 


The following section describes the way in which the mem- 
ory management hardware enables the operating system 
to map virtual addresses into physical addresses, to pro- 
vide the virtual memory available to a process. 


Virtual-to-Physical Page Mapping 

Virtual address space is divided into pages, wherein a 
page is represented by 512 bytes of contiguously ad- 
dressed memory. The first page begins at byte zero and 
continues to byte 511. The next page begins at byte 512 
and continues to byte 1,023, and so forth. For example, 
decimal and hexadecimal addresses of the first eight 
pages of virtual addresss space are: 


The size of a virtual page exactly corresponds to the size of 
a physical page of memory and the size of a block on disk. 


To make memory mapping efficient, the processor must 
be capable of rapidly translating virtual addresses to 
physical addresses. Two features that provide rapid ad- 
dress-translation are the processor’s internal address 
translation buffer and the translation algorithm itself. 


Figure 4-6 compares the virtual address format to the 
physical address formats of the VAX-11/780, the VAX- 
11/750, and the VAX-11/730 processors. The high-order 
two bits of a virtual address immediately identify the region 
to which the virtual address refers. Whether the address is 
physical (processor-specific) or virtual, the byte within the 
page is the same. Thus, the processor has to know only 
which virtual pages correspond to which physical pages. 


VAX-11 VIRTUAL ADDRESS 


PAGE ADDRESS(10) ADDRESS(16) 
decimal hexadecimal 
0 0000-0511 0000-01FF 
1 0512-1023 0200-03FF 
2 1024-1535 0400-05FF 
3 1536-2047 0600-07FF 
4 2048-2559 0800-09FF 
5 2560-3071 0A00-OBFF 
6 3072-3583 0C00-ODFF 
7 3584-4095 OE00-OFFF 
3) 30 29 
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Figure 4-6 
Virtual and Physical Address Formats 
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Figure 4-7 
Page-Table Entry 


The processor has three pairs of page-mapping registers 
— one pair for each of the three regions actively used. The 
operating system’s memory management software loads 
each pair of registers with the base-address and length-of- 
data structures it sets up; these are called page tables. The 
page tables provide the mapping information for each 
virtual page in the system. There is one page table for each 
of the three regions. 


A page table is a virtually contiguous array of page-table 
entries. Each page-table entry is a longword representing 
the physical mapping for one virtual page. To translate a 
virtual address to a physical address, therefore, the proc- 
essor simply uses the virtual page number as an index into 
the page table from the given page-table base address. 
Each translation is good for 512 virtual addresses, since 
the byte within the virtual page corresponds to the byte 
within the physical page. 

Figure 4-7 shows the format of a page-table entry. The 
high-order bits are used to indicate the page’s status and 
protection. The page’s protection can be set to prevent 
read and/or write access by any mode (kernel, executive, 
supervisor, or user). The page’s status indicates what the 
remainder of the page-table entry means. It may be, for 
example, a page address in physical address space, a disk 
sector, or a temporary pointer to a page shared by two or 
more processes. The system’s virtual memory is a dy- 
namic memory that is defined by the physical memory and 
by disk pages that are virtually mapped by page-table en- 
tries. 


The operating system’s memory management software 
maintains the page-table entry protection and status bits, 
with the exception of the modified page bit. The processor 
sets the modified page bit to indicate that it has written into 
a physical page in memory. This is used to keep disk I/O to 
a minimum when paging a process. 
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The processor uses the page-table base registers to locate 
the page tables and uses the length registers as a validity 
check to ensure that any given virtual page is in the range 
of defined page-table entries. Figure 4-8 summarizes and 
compares the page-table structures. 


All process page tables have virtual addresses in the sys- 
tem region of virtual address space, but the system region 
page table is located by its address in physical memory. 
That is, the system region page, table base register con- 
tains the physical address of the page-table base, while 
the process page-table base registers contain the virtual 
addresses of their page-table bases. Because a per-proc- 
ess page-table entry is referred to by a virtual address in 
the system region, the hardware translates its virtual ad- 
dress using the system page table. 


There are two advantages to using a virtual address as the 
base address of a per-process page table. The first advan- 
tage is that all page tables do not have to reside in physical 
memory. The system region page table is the only page 
table that needs to be resident in physical memory. All 
process page tables can reside on disk; that is, process 
page tables can themselves be paged and swapped as 
necessary. 


The second advantage is that the operating system’s 
memory management software can allocate per-process 
page tables dynamically, because the per-process page 
tables do not need to be mapped into contiguous physical 
pages. And although the system region page table must be 
mapped into contiguous physical pages, this requirement 
does not restrict physical memory allocation. The region is 
shared among processes and, therefore, does not require 
redefinition from context to context. 


To illustrate the efficiency of this memory-mapping 
scheme, suppose that 16 processes, each of which is us- 
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Figure 4-8 
Page Tables 


ing four Mbytes of virtual address space, are known to the 
system at the same time (for a total of 64 Mbytes of virtual 
address space). One system page-table entry maps one 
page of per-process page table entries, and one page of 
per-process page table entries maps 65,536 (64K) bytes of 
virtual address space (since it is possible to store 128 
page-table entries in a single page of memory). Therefore 
one page of the system page table maps 128 pages of per- 
process page tables, which in turn maps eight Mbytes of 
process virtual address space. Thus the system region 
page table needed to map these 16 processes requires 
approximately eight physical pages (four Kbytes) of mem- 
ory. 


Exception and Interrupt Vectors 

The processor can automatically initiate changes in the 
normal flow of program execution. The processor recog- 
nizes two kinds of events that cause it to invoke conditional 
software: exceptions and interrupts. Some exceptions, 
such as arithmetic traps, affect an individual process only; 
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others affect the system as a whole — for example, ma- 
chine check. Interrupts include both device interrupts, 
such as those signaling |/O completion, and software- 
requested interrupts, such as those signaling the need for 
a context-switch operation. 


The processor knows which software to invoke when an 
exception or interrupt occurs because it references spe- 
cific locations, called vectors, to obtain the starting ad- 
dress of the exception or interrupt dispatcher. The proces- 
sor has one internal register, the System Control Block 
Base Register that the operating system loads with the 
physical address of the base of the System Control Block, 
which contains the exception and interrupt vectors. The 
processor locates each vector by using a specific offset 
into the System Control Block. Figure 4-9 illustrates the 
vectors in the System Control Block. Each vector tells the 
processor how to service the event and contains the sys- 
tem region virtual address of the routine to execute. Note 
that vector 14 (hex) can be used as a trap to writable con- 
trol store to execute user-defined instructions, and the 
vector contains information passed to microcode. 
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Figure 4-9 
System Control Block 
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Table 4-4 
Interrupt Priority Levels 


PRIORITY 
Hex Decimal 


1E 30 
1D 29 


interrupt Priority Levels 

Exceptions do not require arbitration since they occur syn- 
chronously with respect to instruction execution. Inter- 
rupts, on the other hand, can occur at any time. To arbi- 
trate between interrupt requests that can occur 
simultaneously, the processor recognizes 32 interrupt pri- 
ority levels. 


The highest 16 interrupt priority levels are reserved for in- 
terrupts generated by hardware, and the lowest 16 inter- 
rupt priority levels are reserved for interrupts requested by 
software. Table 4-4 lists the assignment of each level, from 
highest to lowest priority. Normal user software runs at 
process level, which is interrupt priority level zero. 


To handle interrupt requests, the processor enters a spe- 
cial systemwide context. In the systemwide context, the 
processor executes in kernel mode using a special stack 
called the interrupt stack. The interrupt stack cannot be 
referenced by any user-mode software because the proc- 
essor only selects the interrupt stack after an interrupt, 
and all interrupts are trapped through system vectors. 
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The interrupt service routine executes at the interrupt pri- 
ority level of the interrupt request. When the processor re- 
ceives an interrupt request at a level higher than that of the 
currently executing software, the processor honors the re- 
quest and services the new interrupt at its priority level. 
When the interrupt service routine issues the REI (Return 
from Exception or Interrupt) instruction, the processor re- 
turns control to the previous level. 


I/O Space and I/O Processing 

An |/O device controller has a set of control/status and 
data registers. The registers are assigned addresses in 
physical address space, and their physical addresses are 
mapped — and thus protected — by the operating sys- 
tem’s memory management software. That portion of 
physical address space in which device controller regis- 
ters are located is called I/O space. 


No special processor instructions are needed to reference 
I/O space. The registers are simply treated as locations 
containing integer data. An I/O device driver issues com- 
mands to the peripheral controller by writing to the con- 


troller’s registers as if they were physical memory loca- 
tions. The software reads the registers to obtain the 
controller status. The driver controls interrupt enabling 
and disabling on the set of controllers for which it is re- 
sponsible. When interrupts are enabled, an interrupt oc- 
curs when the controller requests it. The processor ac- 
cepts the interrupt request and executes the driver’s 
interrupt service routine if it is not currently executing ona 
higher-priority interrupt level. 


Process Context 

For each process eligible to execute, the operating system 
creates a data structure called the software process-con- 
trol block. Within the software process-control block is a 
pointer to a data structure called the hardware process 
control block. The hardware process-control block is illu- 
strated in Figure 4-10. It contains the hardware process 
context, that is, all the data needed to load the processor’s 
process-specific registers when a context switch occurs. 
To give control of the processor to a process, the operat- 
ing system loads the processor’s Process-Control Block 
Base register with the physical address of a hardware 
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process-control block and issues the Load Process-Con- 
text instruction. The processor loads the process-context 
in one operation and is ready to execute code within that 
context. 

As can be seen from the illustration, a process-control 
block not only contains the state of the programmable 
registers, it also contains the definition of the process 
virtual address space. Thus, the mapping of the process is 
automatically context-switched. 


Furthermore, the process-control block provides the me- 
chanism for triggering asynchronous system traps to user 
processes. The Asynchronous System Trap field enables 
the processor to schedule a software interrupt to initiate an 
AST routine and ensure that they are delivered to the 
proper access mode for the process. 


CONSOLE 

The console is the operator’s interface to the central proc- 
essor. Using the console terminal, the operator can exam- 
ine and deposit data in memory locations or in the proces- 
sor registers, halt the processor, step through instruction 
streams, and boot the operating system. 


Figure 4-10 
Hardware Process-Control Block 


4-25 


THE VAX-11/780 PROCESSOR 


INTRODUCTION 


A VAX-11 processor is a specific set of hardware logic that 
performs the operations of the computer system accord- 
ing to the VAX-11 architecture. 


THE VAX-11/780 PROCESSOR 

This section describes the implementation-specific details 

of the VAX-11/780 processor. Its integrated components 

are: 

e The Central Processing Unit (CPU) itself, including its 
cache, writable diagnostic control store, optional float- 
ing-point accelerator, clocks, and console. 


@ Main memory and main memory controllers. 
@ input/output bus adapters. 

@ Optional multiport memory. 

® Optional high-performance 32-bit interface. 


These components communicate over a high-speed inter- 
nal bus called the memory interconnect. Figure 4-11 illu- 
strates the major processor components. 


The Central Processing Unit performs the logical and 
arithmetic operations requested of the computer system. 
Its user-programmable registers include 16 32-bit general 
purpose registers for data manipulation and the Processor 
Status Longword for controlling the execution states of the 
CPU. The processor’s instruction set is interpreted by the 
microcode contained in its control store. 


The processor includes 12 Kbytes of writable diagnostic 
control store for updating the instruction set microcode. 
The writable diagnostic control is also used for storing mi- 
crocode diagnostics that can be loaded from the console’s 
floppy disk. 
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The processor will also support 12 Kbytes of user-writable 
control store (WCS). WCS is optionally available to the 
customer for augmenting the speed and power of the ba- 
sic machine with customized functions. 


The console enables the computer system operator to 
control the processor operation directly. The console actu- 
ally consists of an LSI-11 microcomputer with 24 Kbytes of 
memory, a floppy-disk system, and a terminal. A serial line 
interface is optionally available for remote diagnosis. 


Two memory controllers can be be connected to the mem- 
ory interconnect. Each controller handles up to 4096 
Kbytes of semiconductor memory, for a system total of 
8192 Kbytes of memory. The memory controllers employ 
an error-detecting and -correcting technique that ensures 
correction of all single-bit errors and detection of all dou- 
ble-bit errors. 


In addition, VAX-11/780 supports the multiported memory 
option. Multiported memory supports very high through- 
put interprocessor communications. Multiported memory 
is discussed more fully in the Peripherals section. 


Three I/O bus adapters can be interfaced to the memory 
interconnect: an adapter for the MASSBUS, which con- 
nects high-speed disk and magnetic tape devices to the 
processor; an adapter for the UNIBUS, which connects 
lower-speed devices to the processor, including disks, 
communications lines, and I/O peripherals such as termi- 
nals, lineprinters, and cardreaders; and an optional adap- 
ter for the high-performance 32-bit interface. The high 
performance interface enables the user to interface cus- 
tom devices directly to the memory interconnect, or to 
connect VAX-11/780 systems together. The high perform- 
ance interface will be discussed more thoroughly in the 
Peripherals section. 
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VAX-11/780 Processor 


VAX-11/780 PROCESSOR COMPONENTS 
Described below are the major hardware components of 
the VAX-11/780 processor. 


VAX-11/780 Console 

The VAX-11/780’s integrated console consists of an LSI- 
11 microcomputer with 16 Kbytes of read/write memory 
and eight Kbytes of ROM (used to store the LSI diagnostic, 
the LSI bootstrap, and fundamental console routines), a 
floppy-disk system (for the storage of basic diagnostic 
programs and software updates), a hardcopy terminal, 
and an optional remote diagnosis port. 


The console is further used for updating the software with 
maintenance releases and for loading optional software 
products distributed on floppy disk. 


The operator communicates with the VAX-11/780 console 
via a set of user-oriented, English-like commands known 
as the console command language (CCL). 


An EIA serial line interface and modem can be added to 
the console to provide remote diagnosis. 


VAX-11/780 MEMORY INTERCONNECT 

The memory interconnect is the system's internal bus; it 
conveys addresses, data, and control information between 
the processor and memory and between memory and the 
I/O controllers. The memory interconnect has a cycle time 
of 200 nanoseconds and can transfer 32 bits each cycle. 
Data transfers use two consecutive cycles to transfer 64 
bits at a time. The maximum memory interconnect transfer 
rate is 13.3 million bytes per second. The memory inter- 
connect provides an unusual degree of throughput and re- 
liability because it uses: 

® Time-division multiplexing 

e Distributed priority arbitration 
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® Parity and protocol checking on every transfer 
® Transaction history recording 


The protocol, or sequence in which operations occur on 
the memory interconnect, is time-division-multiplexed to 
increase the effective bus bandwidth. Time-division multi- 
plexing means that the transactions that constitute one 
transfer operation are interleaved with the transactions 
which constitute another transfer operation. Thus, several 
operations can be in progress over the same period of 
time. For example, the CPU can ask a memory controller 
to read some data; the same memory controller might then 
transfer previously requested data to an I/O device before 
it transfers the requested data to the CPU. 


In some systems, the processor bus can be tied up for 
each transfer because a requester acquires the bus to 
send an address and then keeps the bus while it waits for 
the requested data. In VAX-11/780, the bus is not held in- 
active during the data access time because bus ownership 
is relinquished after every cycle. A requester acquires the 
bus to specify an operation and send an address, and re- 
linquishes the bus. At some later time the responder ac- 
quires the bus to send back the requested data. In the 
interim, any number of other transactions can be initiated 
or completed. This, and the fact that transactions are buff- 
ered, make it possible for the bus to operate at its full 
bandwidth. 

Arbitration on the memory interconnect is distributed; this 
ensures that no unit is critical to bus operation. Every unit 
on the memory interconnect has its own arbitration line. 
Arbitration lines are ordered by priority, and every unit 
monitors all the arbitration lines every cycle to determine if 
it will get the next cycle. Unlike some bus systems, any unit 
on the memory interconnect (except the CPU clock) can 
fail without causing a failure of the entire bus. 


To ensure the integrity of the signals transmitted, the 
memory interconnect includes several error-checking and 
diagnostic mechanisms, such as: 

e Parity checking on data, addresses, and commands. 

® Protocol checking in each interface. 

e A history silo of the last 16 memory interconnect cycles. 


VAX-11/780 MAIN MEMORY AND CACHE SYSTEMS 

The processor includes both main memory systems and 
cache memory systems. Transactions between main 
memory and the processor take place over the memory in- 
terconnect. The cache memory systems are internal to the 
processor. 


Main Memory 

Main memory consists of arrays of MOS RAM integrated 
circuits with a cycle time of 600 nanoseconds. A memory 
controller can access a maximum of 4,194,304 bytes (four 
Mbytes). Two memory controllers can be connected to the 
memory interconnect, yielding a maximum of eight Mbytes 
of physical memory that can be available on the system. 
The maximum total physical address space is 2?9 — ap- 
proximately 512 million bytes. However, the minimum re- 
quired memory is 256 Kbytes, which is then expandable in 
increments of 256 Kbytes. 


A memory controller will buffer one command while it 
processes another to increase system throughput. Main 
memory can also be interleaved (if two memory controllers 
are each addressing the same amount of memory) to in- 
crease the available memory bandwidth. The memory sys- 
tem employs error checking and correction (ECC) that 
corrects all single-bit errors and detects all double-bit er- 
rors. 


When the system is powered down, an ac standby current 
is normally used to retain the contents of memory. In case 
of temporary ac power interruption, an optional backup 
battery is also available to provide ten minutes of power 
for up to four Mbytes of memory so that the contents of 
main memory are not destroyed. Two backup batteries 
provide power for up to eight Mbytes of memory. 


Data are fetched from main memory 64 bits at a time (two 
memory interconnect cycles) and cached in the proces- 
sor’s internal memory systems. The internal memory sys- 
tems include a main memory cache, an address transla- 
tion buffer, and an instruction look-ahead buffer. 


Memory Cache 

The memory cache is the primary cache system for all data 
coming from memory, including addresses, address 
translations, and instructions. The memory cache is an 
eight Kbyte, two-way set associative, write-through cache. 


Write-through provides reliability because the contents of 
main memory are updated immediately after the proces- 
sor performs a write. Most write-through cache systems tie 
up the processor while main memory is updated. However, 
the VAX-11/780 processor buffers data to be written to 
memory to avoid waiting while main memory is updated 
from the cache. Therefore, while providing the reliability of 
a write-through cache, this system also provides much the 
same performance as a write-back cache. 


Memory cache significantly reduces processor wait time 
since practically all of the time, (greater than 95 percent), 
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the data are in the cache. The cache memory system car- 
ries byte parity for both data and addresses for increased 
integrity. 


Address Translation Buffer 

The address translation buffer is a cache of virtual-to- 
physical address translations. It significantly reduces the 
amount of time spent by the CPU on the repetitive task of 
dynamic address translation. The cache contains 128 
virtual-to-physical page-address translations that are di- 
vided into equal sections: 64 system-space page transla- 
tions and 64 process-space page translations. Each sec- 
tions is two-way associative. There is byte parity on each 
entry for increased integrity. 


Instruction Buffer 

The eight-byte instruction buffer improves CPU 
performance by prefetching data in the instruction stream. 
The control logic continuously fetches information from 
memory or cache, where possible, to keep the eight-byte 
buffer full. It effectively eliminates the time spent by the 
CPU waiting for two memory cycles where bytes of the in- 
struction stream cross 32-bit longword boundaries. In ad- 
dition, the instruction buffer processes operand specifiers 
in advance of execution and subsequently routes them to 
the CPU. 


1/0 CONTROLLER INTERFACES 

Peripherals can be connected to the processor’s memory 
interconnect bus in either of two ways: through the MASS- 
BUS, for high-speed disk and/or magnetic tape devices, 
or through the UNIBUS, for a variety of I/O devices, 
including lineprinters, disks, cardreaders, terminals, and 
interprocessor communication links. 


VAX-11 MASSBUS Interface 

The processor interface for a MASSBUS peripheral is the 
MASSBUS adapter. The MASSBUS adapter performs 
control, arbitration, and buffering functions. Up to four 
MASSBUS adapters can be connected to the memory in- 
terconnect. The MASSBUS is typically used to attach high- 
speed disk or magnetic-tape devices. 


Each MASSBUS adapter includes its own address transla- 
tion map that permits scatter/gather disk transfers. In 
scatter/gather transfers, physically contiguous disk blocks 
can be read into or written from discontiguous blocks of 
memory. The translation map contains the addresses of 
the pages; pages can be scattered throughout memory, 
from or to which the contiguous disk transfer takes place. 


Each MASSBUS adapter includes a 32-byte silo data 
buffer. Data are assembled in 64-bit quadwords (plus 
parity) to make efficient use of the memory interconnect 
bandwidth. On transfers from memory to a MASSBUS 
peripheral, the MASSBUS adapter anticipates upcoming 
MASSBUS data transfers by fetching the next 64 bits from 
memory before all of the previous data have been trans- 
ferred to the peripheral. 


Online diagnostics and builtin loopback testing enable 
fault isolation of the MASSBUS adapter for any of its func- 
tion circuits without a drive on the MASSBUS. 


VAX-11/780 UNIBUS Interface 

All devices other than the high-speed disk drives and 
magnetic-tape transports are connected to the UNIBUS — 
an asynchronous bidirectional bus. These include all 
DIGITAL-developed and user-developed realtime peri- 
pherals. The UNIBUS is connected to the memory inter- 
connect through the UN/BUS adapter. The UNIBUS adap- 
ter performs priority arbitration among devices on the 
UNIBUS. Up to four UNIBUS adapters can be placed on 
the memory interconnect. 


The UNIBUS adapter provides access from the VAX- 
11/780 processor to the UNIBUS peripheral device regis- 
ters by translating UNIBUS addresses, data transfer re- 
quests, and interrupt requests to their memory intercon- 
nect equivalents, and vice versa. The UNIBUS adapter 
address translation map translates an 18-bit UNIBUS ad- 
dress to a 30-bit memory interconnect address. The map 
provides direct access to system memory for nonproces- 
sor request UNIBUS peripheral devices and permits scat- 
ter/gather disk transfers. 


The UNIBUS adapter enables the processor to read 
and/or write the peripheral controller registers. In some 
cases this constitutes the transfer. 


To make the most efficient use of the memory interconnect 
bandwidth, the UNIBUS adapter provides buffered direct 
memory access data paths for up to 15 nonprocessor re- 
quest (NPR) devices. Each of these channels has a 64-bit 
buffer (plus byte parity) for holding four 16-bit transfers to 
and from UNIBUS devices. The result is that only one 
memory interconnect transfer (64 bits) is required for ev- 
ery four UNIBUS transfers. The maximum aggregate 
transfer rate through the buffered data paths is 1.35 mil- 
lion bytes per second. On memory interconnect-to-UNI- 
BUS transfers, the UNIBUS adapter anticipates upcoming 
UNIBUS requests by prefetching the next 64-bit quadword 
from memory as the last 16-bit word is transferred from 
the buffer to the UNIBUS. By the time the UNIBUS device 
requests the next word, the UNIBUS adapter has it ready 
to transfer. 


Any number of unbuffered direct memory access transfers 
are handled by one Direct Data Path. Every eight- or 16-bit 
transfer requires one 32-bit transfer on the memory inter- 
connect. The maximum transfer rate through the Direct 
Data Path is 500,000 bytes per second. 


The UNIBUS adapter permits concurrent program inter- 
rupt, unbuffered, and buffered data transfers. The aggre- 
gate throughput rate of the Direct Data Path, plus the 15 
buffered data paths, is 1.35 million bytes per second. 
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Data Throughput 

VAX-11/780 includes many features that support high data 
throughput, including silo data buffers for MASSBUS peri- 
pheral controllers, buffered direct memory access for the 
UNIBUS peripherals, and 64-bit data transfers and 
prefetching. 


Memory bandwidth matches that of the processor’s inter- 
nal bus — 13.33 million bytes per second, including time 
for refresh cycles. This is primarily because of the memory 
controller request buffers that substantially increase mem- 
ory throughput and overall system throughput and de- 
crease the need for interleaving for most configurations. 
Memory interleaving, which is enabled and disabled under 
program control, can be used effectively when more than 
two MASSBUS peripheral controllers are connected and 
the MASSBUS and UNIBUS devices are transferring at 
very high rates — greater than one million bytes per sec- 
ond. 


The operating system supports the hardware throughput 
in its |1/O request processing software. The software uses 
the processor’s multiple hardware priority levels to in- 
crease |I/O response time and keeps each disk controller 
as busy as possible by overlapping seek requests with I/O 
transfers. 


VAX-11/780 Floating-point Accelerator 

The floating-point accelerator (FPA) is an optional high- 
speed processor enhancement. When included in the 
processor, the floating-point accelerator accelerates the 
execution of the addition, subtraction, multiplication, and 
division instructions that operate on single-precision and 
double-precision floating-point operands. This includes 
the special EMOD and POLY instructions in both single- 
precision and double-precision formats. Additionally, the 
floating-point accelerator enhances the performance of 
the 32-bit-integer multiply instruction _MUL. 


The processor does not have to include the floating-point 
accelerator to execute floating-point operand instructions; 
the FPA increases the execution speed of floating-point in- 
structions. The floating-point accelerator can be added or 
removed without changing any existing software. 


When the floating-point accelerator is included in the 
processor, a floating-point register-to-register add in- 
struction takes as little as 800 nanoseconds to execute. A 
register-to-register multiply instruction takes as little as 
one microsecond. Therinner loop of the POLY instruction 
takes approximately one microsecond per degree of poly- 
nomial. 


THE VAX-11/782 PROCESSOR 


INTRODUCTION 

The VAX-11/782 attached processor system is the new 
high-end member of the VAX family of computers. The 
VAX-11/782 is a tightly coupled asymmetric multiproces- 
sor system based on the MA780 shared memory subsys- 
tem. It comprises two VAX-11/780 CPUs and up to 8 
Mbytes of MA780 shared memory. Like all the family 
members, it implements the VAX 32-bit architecture and is 
a fully supported product. 


The VAX-11/782 offers a performance improvement of 60 
to 80 percent over a single VAX-11/780. Complementing 
its high performance, the VAX-11/782 is easy to imple- 
ment and use. Applications can be transferred from a sin- 
gle to an attached processor configuration without requir- 
ing additional development or debugging efforts. 


The two processors communicate through the MA780 
memory. All peripheral devices are connected to one of 
the CPUs that functions as the primary processor. Users 
who currently own a VAX-11/780 can easily upgrade to a 
VAX-11/782 and realize a significant increase in perform- 
ance. 


Figure 4-12 illustrates the major processor components. 


THE VAX-11/782 ATTACHED PROCESSOR 

The VAX-11/782 attached processor is available as a com- 

plete packaged system or as an upgrade option to a single 

processor VAX-11/780 system. The integrated compo- 

nents of the VAX-11/782 system are: 

e Two Central Processing Units (CPUs) each with a 
console, cache, cache invalidation option, and clocks. 


e MA780 shared memory subsystem. 


4-30 


® Battery backup. 
® Optional floating-point accelerators. 


The attached processor does not support any I/O peri- 
pherals. All 1/O devices and peripherals are connected to 
the primary processor. Both VAX-11/780s must be at the 
same revision level and the same version of microcode. 
The Writable Control Store (WCS) option, the DR780, and 
the 2.2 Mbyte-per-sec RPO7 are not supported. 


Multiprocessing 

In a tightly coupled system, the CPUs share the same op- 
erating system code and data structures. Asymmetric 
CPUs cannot execute the entire operating system code at 
the same time. All kernel-mode and interrupt code is exe- 
cuted only by the primary processor, thereby eliminating 
the need for complex synchronization or locking mecha- 
nisms of various data structures. The primary processor 
conducts all |/O operations and schedules all work for the 
secondary processor before scheduling itself. 


The VAX/VMS scheduler dynamically allocates compute- 
intensive functions to the attached processor and func- 
tions that require I/O transfers to the primary processor. 


Shared Memory Subsystem 

Each CPU has local memory for diagnostics. The upgrade 
attached processor is delivered with one Mbyte of shared 
memory expandable up to eight Mbytes. The packaged 
systems are available with a choice of shared memory 
sizes and are also expandable up to a maximum of eight 
Mbytes. 
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Figure 4-12 
VAX-11/782 PROCESSORS 


Battery Backup 

Battery backup support is included for the attached proc- 
essor system configurations. Two backup units that reside 
within the MA780 cabinet are capable of supporting four 
Mbytes of memory for a minimum of ten minutes. Smaller 
amounts of memory are supported for longer periods of 
time. This level of support is sufficient to protect the mem- 
ory contents from the vast majority of power interruptions. 


Console Subsystem 

The VAX-11/782 console subsystem is designed to allow 
the user to give commands interactively to the processor 
via a console command language. Three elements com- 
bine to give the user access to the system’s capabilities: a 
set of machine status switches on the processor's front pa- 
nel, an LA120 console terminal, and an integral floppy- 
disk drive. Simple console commands entered through the 
console terminal replace the traditional toggle switches 
and provide operational control (i.e., bootstrapping, ini- 
tialization, selftesting, examining/depositing data in mem- 
ory, etc.). When the console terminal is not being used to 
communicate console command language instructions to 
the processor, it can function as a VAX system terminal. 


The remote diagnosis module is an option available to 
customers with a full DIGITAL maintenance contract. It 
provides the customer with dial-in diagnosis (24 hours a 
day, seven days a week, with a 15-minute response time), 
including detection of failures down to the board and chip 
level, and diagnostic capability even on an inoperative 
CPU. 


Fault Handling 

Many VAX/VMS features have been extended for use on 
multiprocessing systems, including powerfail, bugcheck, 
machine check, automatic restart, and error logging. 
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Powerfail has been implemented so that, in the event the 
attached processor loses power, it will transfer the jobs it 
currently has and the primary will continue to run without 
the loss of any data. When power is restored, the attached 
processor will resume its work. If the primary power fails, 
the attached processor will wait for it to restart. 


A bugcheck will stop execution on both processors and 
can be initiated by either processor. The processors will 
synchronize during the bugcheck. Both can be set to auto- 
matically reboot. 


A multiprocessing system conducts machine-checks and 
error logging in a manner similar to a single-processor 
system. The error-log entries now also include the system 
ID, allowing recognition of the processor that made an er- 
ror. 


Cache Invalidation Logic 

The MA780 has been designed to virtually eliminate the 
problem of incorrect or stale data in the CPU caches. After 
a write to a multiport memory location, the MA780 sends 
an invalidate signal to each CPU. This signal transmits an 
address to each CPU; each CPU then checks to see if its 
cache contains that address. If so, it marks the contents as 
invalid, and on subsequent reads by the CPU this invalida- 
tion forces the CPU to seek the new information from 
shared memory. The VAX-11/782 cache therefore retains 
its transparency to software. 


Selective Cache Invalidation 

For the attached processor systems, the Selective Cache 
Invalidation option has been included. This allows multi- 
computer systems that have considerable traffic on a sys- 
tem’s SBI to send invalidate signals only to the CPU that 


has accessed a given location in MA780 memory. This op- 
tion for shared memory is called an invalidation map, and 
its operation is quite straightforward. It contains one entry 
for each 64-bit quadword in shared memory; and the entry 
contains four bits — one for each CPU. Whenever a CPU 
reads a 64-bit quadword from shared memory, the MA780 
controller sets the bit in the correct invalidation map entry. 
The next time a CPU writes into that 64-bit quadword, the 
MA780 controller notifies only those CPUs whose bits have 
been set in the invalidation map. Once that has been done, 
all the bits are cleared, except for the bit of the CPU 
performing the write operation. In this way, the overall traf- 
fic on all SBls and the cache activity are kept to a minimum 
while data integrity is still maintained. 


Clocks 

Two clocks are contained in each processor. The high-re- 
solution programmable realtime clock is used by systems 
diagnostics and by the VAX/VMS operating system for ac- 
counting and scheduling. The time-of-year clock, which 
has its own battery backup, is used by the operating sys- 
tem to enable unattended automatic restart following any 
service interruption, including a power failure. 


The VAX-11/782 Primary Processor I/O Subsystems 

The VAX-11/782 primary processor internal data paths 
and |/O structure are well adapted for running large pro- 
grams or a large quantity of programs, for superior data 
handling, and for rapid communication between I/O de- 
vices and the processor. The I/O structure includes a data 
and control path that transmits 32-bit data or control infor- 
mation every 200 nanoseconds. It moves as much as 13.3 
Mbytes of data per second among the system’s major 
hardware components. The I/O structure supports up to 
four UNIBUS and four MASSBUS adapters — the inter- 
connects that link this path to disks and other peripherals. 
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Compatibility Mode 

In compatibility mode, the processor executes the user set 
of PDP-11 instructions, recognizes integer data, and uses 
eight 16-bit general purpose registers. This allows the 
VAX-11/782 system user to run most existing nonprivi- 
leged RSX-11M and RSX-11S operating system software, 
including compilers, utilities, and user programs. Pro- 
grams that use compatibility-mode instructions can exe- 
cute concurrently with native-mode programs. 


VAX-11/782 Floating-Point Accelerators 

The floating-point accelerators (FPA) are optional high- 
speed processor enhancements. If one is present on the 
primary processor, another must also be included on the 
attached processor. The floating-point accelerator per- 
forms the execution of the addition, subtraction, multipli- 
cation, and division instructions that operate on single- 
precision and double-precision floating-point operands. 
This includes the special EMOD and POLY instructions in 
both single-precision and double-precision formats. Addi- 
tionally, the floating-point accelerator enhances the per- 
formance of the 32-bit-integer multiply instruction _MUL. 


The processor does not have to include the floating-point 
accelerator to execute floating-point operand instructions; 
the FPA increases the execution speed of floating-point in- 
structions. The floating-point accelerator can be added or 
removed without changing any existing software. 


When the floating-point accelerator is included in the 
processor, a floating-point register-to-register add _ in- 
struction takes as little as 800 nanoseconds to execute. A 
register-to-register multiply instruction takes as little as 
one microsecond. The inner loop of the POLY instruction 
takes approximately one microsecond per degree of poly- 
nomial. 


THE VAX-11/750 PROCESSOR 


INTRODUCTION 

The VAX-11 processor is a specific set of hardware logic 
that performs the operations requested of the computer 
system according to the VAX-11 architecture. 


THE VAX-11/750 PROCESSOR 

This section describes the implementation specific details 

of the VAX-11/750 processor. Its integrated components 

are: 

e The Central Processing Unit (CPU) itself, including its 
cache, optional floating-point accelerator, user control 
store, clocks and console. 


e Main memory and main memory controller. 
e Peripheral bus adapters. 


Figure 4-13 illustrates the major VAX-11/750 processor 
components. 


The Central Processing Unit performs the logical and 
arithmetic operations requested of the computer system. 
Its user-programmable registers include sixteen 32-bit 
general purpose registers for data manipulation and for 
the Processor Status Word that controlls the execution 
states of the CPU. The processors instruction set is 
defined by the microcode contained in its control store. 


The optional User Control Store includes ten Kbytes (one 
Kbytes of 80-bit microwords) of writable storage. This 
allows customers to augment the speed and power of the 
basic machine with customized microcode functions. 
DIGITAL offers a loadable microcode package for 
extended-precision floating-point arithmetic operations 
(G- and H-floating-point data types) on the VAX-11/750. 
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The console enables the computer system operator to 
control the processor operation directly. The console 
subsystem consists of the console terminal, the front 
panel, the user-oriented console command language, and 
a TU58 Tape-Cartridge Drive. Also optionally available for 
the console is the remote diagnosis interface. 


The main memory subsystem consists of ECC MOS 
memory that is interfaced to the system via the memory 
controller. MOS memory can be added to the system in 
increments of 256 Kbytes or one Mbyte to a maximum of 
two Mbytes or eight Mbytes, depending upon the VAX- 
11/750 system configuration. 


The I/O subsystem consists of the UNIBUS and MASSBUS 
devices connected to the system via special buffered 
interfaces called adapters. Each VAX-11/750 system 
contains one UNIBUS adapter for standard peripherals 
and up to a maximum of three MASSBUS adapters for 
high-speed peripherals. Users can optionally substitute a 
second UNIBUS adapter in place of one of the MASSBUS 
adapters. 


VAX-11/750 PROCESSOR COMPONENTS 
Described below are the major hardware components of 
the VAX-11/750 processor. 


VAX-11/750 Console 

The console enables the computer system operator to 
control the processor operation directly. The console sub- 
system consists of the console terminal, the front panel, 
the user-oriented console command language, and a 
TU58 Tape-Cartridge Drive. Simple console commands 
entered through the console terminal, replace the tradi- 
tional toggle switches and provide operational control (i.e., 
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Figure 4-13 
VAX-11/750 Processor 


bootstrapping, initialization, selftesting, examining and de- 
positing data in memory, etc.). When not performing oper- 
ator functions or error logging, the same terminal can be 
available to authorized users for normal system 
operations. 


The VAX-11/750 console subsystem and the console com- 
mand language also facilitate the loading of diagnostics 
and software updates from the TU58 Tape Cartridge. For 
those customers subscribing to a DIGITAL maintenance 
contract, the console subsystem can also be equipped 
with a remote diagnosis module (RDM) allowing the VAX- 
11/750 to interface to a host computer at a DIGITAL Diag- 
nostic Center for remote fault detection or preventive 
maintenance procedures. 


VAX-11/750 Floating-point Accelerator 

The floating-point accelerator is an optional high-speed 
processor that can be added to the VAX-11/750 CPU. 
When included in the processor, the floating-point accel- 
erator increases the speed of execution of addition, sub- 
traction, multiplication, and division instructions that oper- 
ate on single-precision and double-precision floating- 
point operands, including the EMOD (range reduction of 
math-function arguments) and POLY (polynomial calcula- 
tion) instructions. In addition, the floating-point accelera- 
tor increases the speed of execution of 32-bit-integer mul- 
tiplication instructions. 


When the floating-point accelerator is included in the 
processor, a floating-point operand register-to-register 
ADD instruction takes as little as 1.2 microseconds to exe- 
cute. A register-to-register MULTIPLY instruction takes as 
little as 1.3 microseconds. The inner loop of the POLY in- 
struction takes approximately 1.3 microseconds per de- 
gree of polynomial. 
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VAX-11/750 Main Memory 

The VAX-11/750 main memory is built using 16K or 64K 
MOS RAM (random access memory) LSI chips. Physical 
memory is organized into an array of 32-bit longwords 
plus an additional seven bits per longword dedicated to 
ECC (error correcting code). ECC allows the correction of 
all single-bit errors and the detection of all double-bit er- 
rors to ensure data integrity. Main memory is interfaced to 
the VAX system via the memory controller. The VAX- 
11/750 can be easily field-upgraded to two Mbytes or eight 
Mbytes of main memory by simply adding 256 Kbyte or 
one Mbyte expansion modules, depending upon the sys- 
tem configuration. 


VAX-11/750 Cache Systems 

The VAX-11/750 CPU provides three cache systems: the 
main memory cache, the address translation buffer, and 
the instruction buffer. 


Main Memory Cache — 

Memory cache (typically a 90-percent hit rate) provides 
the central processor with high-speed data access by stor- 
ing frequently referenced addresses and data and instruc- 
tion items. The memory cache typically cuts memory ac- 
cess time in half. 


The VAX-11/750 memory cache is a four Kbyte, direct 
mapped, write-through cache. It is used for all data com- 
ing from memory, including addresses and instructions. 
The write-through feature protects the integrity of memory 
because memory contents are updated immediately after 
the processor performs a write. For increased integrity, the 
cache memory system carries byte parity for both data 
and addresses. Cache locations are allocated when data is 
read from memory or when a longword is written to mem- 
ory. Memory cache also watches I/O transfers and up- 


dates itself appropriately. Therefore, no operating system 
overhead is needed to synchronize the cache with I/O op- 
erations, that is, memory cache is transparent to all 
software. 


Instruction Buffer — 

The instruction buffer is an eight byte buffer that enables 
the CPU to fetch and decode the next instruction while the 
current instruction completes execution. The instruction 
buffer in combination with the parallel data paths (which 
can perform integer arithmetic and shifting operations si- 
multaneously) significantly enhance the VAX-11/750’s 
performance because the CPU is not held in a wait state. 


Address Translation Buffer — 

The address translation buffer is a cache of the most fre- 
quently used 512 physical-address translations. It signifi- 
cantly reduces the amount of time the CPU spends on the 
repetitive task of dynamic address translation. The cache 
contains 512 virtual-to-physical page-address translations 
that are divided into equal sections: 256 system-space 
page translations and 256 process space page transla- 
tions. Each section is two-way associative and has parity 
on each entry, for increased integrity. 


Peripheral Controller Interfaces 

Peripherals can be connected to the processor in either of 
two ways: through the MASSBUS, which conveys signals 
to and from high-speed disks or magnetic-tape devices, or 
through the UNIBUS, which conveys signals to and from a 
variety of I/O devices, including lineprinters, disks, car- 
dreaders, tapes, terminals, and interprocessor communi- 
cation links. 


VAX-11 MASSBUS Interface 

The processor interface for a MASSBUS peripheral is the 
MASSBUS adapter. The MASSBUS adapter performs 
control, arbitration, and buffering functions. There can be 
a total of three MASSBUS adapters on each VAX-11/750 
system. 


Each VAX-11/750 MASSBUS adapter includes its own ad- 
dress translation map that permits scatter/gather disk 
transfers. In scatter/gather transfers, physically contigu- 
ous disk blocks can be read into or written from discon- 
tiguous blocks of memory. The translation map contains 
the addresses of the pages that can be scattered through- 
out memory, from or to which the contiguous disk transfer 
takes place. 


Each 11/750 MASSBUS adapter includes a 32-byte silo 
data buffer. Data are assembled in 32-bit longwords (plus 
parity) to make efficient use of the system bus. On trans- 
fers from memory to a MASSBUS peripheral, the MASS- 
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BUS adapter anticipates upcoming MASSBUS data trans- 
fers by fetching the next 32 bits from memory before all of 
the previous data are transferred to the peripheral. 


Online diagnostics and loopback enable adapter fault 
isolation without requiring the use of a drive on the MASS- 
BUS. 


VAX-11/750 UNIBUS Interface 

General purpose peripherals and customer-developed 
devices are connected to the VAX-11/750 system via the 
UNIBUS. Since the VAX-11/750 memory deals in 24-bit 
physical addresses (16 Mbyte physical address space), 
18-bit UNIBUS addresses must be translated to 24 bit 
memory addresses. This mapping function is performed 
by the UNIBUS adapter (a special hardware interface 
between memory and the UNIBUS) that translates UNIBUS 
addresses to their memory equivalents, and vice versa. 


The UNIBUS adapter performs priority arbitration among 
devices on the UNIBUS — a function handled by the cen- 
tral processor in PDP-11 systems. The address translation 
map permits contiguous disk transfers to and from non- 
contiguous pages of memory (these are called scat- 
ter/gather operations). Interrupts on the VAX-11/750 
UNIBUS are directly vectored into the appropriate process 
handler. 


The UNIBUS adapter allows two kinds of data transfers — 
program interrupt and direct memory access (DMA). To 
make the most efficient use of the memory bandwidth, the 
UNIBUS adapter facilitates high-speed DMA transfers by 
providing buffered DMA data paths for up to three high- 
speed devices at one time. Each of these channels has a 
32-bit buffer (plus byte parity) for holding two 16-bit trans- 
fers to or from UNIBUS devices. The result is that only one 
memory transfer (32 bits) is required for every two UNI- 
BUS transfers. The maximum aggregate transfer rate 
through the buffered data paths is 1.5 Mbytes per second. 


Any number of unbuffered DMA transfers are handled by 
one direct DMA data path. Every 8-bit or 16-bit transfer on 
the UNIBUS requires a 32-bit memory transfer (although 
only 16 bits are used). The maximum transfer rate through 
the direct data path is one Mbytes per second. 


It should be noted that the UNIBUS adapter permits pro- 
gram interrupts and unbuffered and buffered data trans- 
fers to occur concurrently. 


In place of one of the optional MBAs, users can insert an 
additional UNIBUS adapter. 


THE VAX-11/730 PROCESSOR 


INTRODUCTION 

The newest member of the VAX family, the VAX-11/730 
central processing unit (CPU), is a 32-bit micropro- 
grammed computer that executes the VAX instruction set 
in native mode and supports the VAX/VMS operating sys- 
tem. Additionally, nonprivileged PDP-11 instructions can 
be executed in compatibility mode, allowing existing user 
mode PDP-11 programs to run without modification. 


THE VAX-11/730 PROCESSOR 

The VAX-11/730 processor is implemented using bit-slice 
and Programmed Array Logic (PAL) technology. The stan- 
dard components of the VAX-11/730 include the Central 
Processing Unit (CPU) with its DAP (data path) module, 
WCS (writable control store) module, MCT (memory con- 
troller) module; one Mbyte memory module; clocks; and 
console subsystem. Integrated into the VAX-11/730 sys- 
tems are the Integrated Disk Controller (IDC) and the 
DMF32 communications controller. Optionally available, 
for both the processor and the systems, are the Floating- 
Point Accelerator (FPA) and up to four additional one 
Mbyte memory modules. 


Figure 4-14 illustrates the major VAX-11/730 components. 


The CPU performs the logic and arithmetic operations 
requested by the computer system users. It uses 32-bit 
virtual addresses, allowing access to 4.3 gigabytes of 
virtual address space. These addresses are called virtual 
because each address is not necessarily the actual ad- 
dress in physical memory. The processor’s memory man- 
agement hardware translates virtual addresses to physical 
addresses. 
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The processor provides sixteen 32-bit registers that can 
be used for temporary storage, as accumulators, index 
registers, and base registers. Four of these registers have 
special significance: the Program Counter (PC), the Stack 
Pointer (SP), and two registers used in the extensive CALL 
facility. 

The native instruction set is highly versatile and bit-effi- 
cient. It includes integer, packed-decimal, character- 
string, bit field, and floating-point instructions, as well as 
program control and special instructions. Instructions and 
data are variable in length and can start on any byte 
boundary or, in the case of bit field data, at any arbitrary 
bitin memory. 


Programmed Array Logic Technology 

Programmed array logic (PAL) devices are logic arrays 
manufactured on a chip using the TTL Schottky bipolar 
process and fusable-link technology. The high logic 
density of PALs decreases the required amount of space 
and reduces cost. 


The basic circuitry used in PALs consists of programm- 
able AND arrays connected to fixed OR arrays. In the PAL 
circuits used in the VAX-11/730, up to 32 programmable 
AND inputs and up to eight fixed OR inputs are used per 
output. 


An unprogrammed PAL — one with all fuses intact — is 
programmed by first determining the AND inputs to be 
used and then “blowing” the links for the unused AND in- 
puts. This produces the desired AND before OR logic con- 
figuration. 


CONSOLE 
SUBSYSTEM 


CPU 


VAX-117730 


I/O ADAPTER 


MEMORY 
1MB MIN 
5 MB MAX 


Figure 4-14 
VAX-11/730 PROCESSOR 


CPU Control Store 

The CPU microcontroller consists of a microsequencer 
and acontrol store. The control store is a programmable 
Read/Write memory with a basic storage capacity of 16 K 
24-bit microwords. An additional 1 K microwords of con- 
trol store is available to support the Integrated Disk Con- 
troller. 


The control store sequences the CPU to implement the na- 
tive and PDP-11 compatibility-mode instruction sets. The 
CPU microcode is loaded into the control store from one of 
the TU58 tape drives during system bootstrap. 


Each microinstruction is 24 bits and contains several con- 
trol fields for specific CPU functions. The sequence of mi- 
croinstructions read from the control store and loaded into 
the control status register (CSR) is determined by the mi- 
crosequencer. 


Internal Data Paths 

The CPU data path performs the arithmetic and logical op- 
erations necessary to execute the instruction set. The prin- 
cipal data path components are 4-bit processor slices. 
Eight of these slices are connected in parallel to give an 
arithmetic and logical processing element 32-bits wide. 
The data path also contains a 256 location by 32-bit local 
store RAM that includes, among other things, the general 
registers and several of the architecturally-defined privi- 
leged processor registers. The data path is controlled by 
microcode executing in the CPU’s microcontroller. 


Console Subsystem 
The VAX-11/730 console subsystem is designed to allow 
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the user to interactively communicate instructions to the 
cental processing unit using the console terminal and the 
console command language. Five major elements make 
up the VAX-11/730 console subsystem: 


1. A front panel on the CPU cabinet with switches and in- 


dicator lights. 


2. Dual TU58 tape cartridge drives in the CPU box. 

3. A separate ASCII terminal, called the console termi- 
nal. 

4. Aspecial user-oriented console command language. 

5. Aremote access port. 


The fundamental function of either of the integrated dual 
TU58 tape drives is to load the CPU microcode. If one of 
the TU58s fails, the second TU58 can be used as a backup. 
In addition, either TU58 drive is used to boot the system, 
load diagnostics, and update operating system software. 
DIGITAL also supports the TU58 under VAX/VMS for sto- 
rage and retrieval. 


The VAX-11/730 console terminal operates in two modes: 
program mode and console mode. When in program 
mode, the console functions like the other terminals on the 
VAX-11/730 system — it passes characters between the 
terminal and the program. When in console mode, the 
CPU is receptive to console commands. The console com- 
mands entered through the console terminal, replace the 
traditional toggle switches and lights. Users communicate 
with the console subsystem using the special console 
command language. 


64 K RAM Chips 

The memory array modules of the VAX-11/730 use 64 K 
MOS (metal oxide semiconductor) RAM chips for data sto- 
rage. 156 RAM chips are arranged in four banks of 39 
chips. Each chip has a 256 by 256 matrix, providing 64 K 
one-bit locations and thus, 64 K 39-bit data locations per 
bank. The four banks yield 1 Mbyte with associated check 
bits. 


VAX-11/730 MAIN MEMORY 

The main memory in the VAX-11/730 consists of from one 
to five memory array modules that use 64K MOS (metal 
oxide semiconductor) RAM chips for data storage. The 
modules are connected to the CPU by the array bus. Up to 
five 1 MB array modules can be installed in the processor 
box to give a maximum memory capacity of 5 MB. The 
minimum memory configuration is 1 MB. 


Memory data transfers over the array bus are 39 bits: one 
32-bit longword (four bytes) of data and seven associated 
ECC (Error-Correcting Code) bits. The ECC bits provide 
for the detection and correction of all single-bit errors 
when a longword is read from the memory array. Double- 
bit errors are detected but not corrected. All errors are re- 
ported back to the CPU where they can be recorded for 
use in preventive and corrective maintenance operations. 


The memory controller (MCT) module contains the mem- 
ory and UNIBUS control logic. The memory control logic 
controls data transfers to and from the main memory array 
modules over the array bus. The UNIBUS control logic 
controls transfers to and from the peripheral devices over 
the UNIBUS. Transfers are initiated by the CPU data path 
under the control of the CPU microcode, or by the UNIBUS 
devices when direct data transfers are made between the 
UNIBUS devices and main memory. 


The memory and UNIBUS control logic contains the fol- 

lowing: 

e A translation buffer that converts virtual addresses from 
the CPU to physical addresses. The physical addresses 
are then applied to the memory array modules. 


e A UNIBUS map that converts 18-bit addresses to physi- 
cal memory addresses. 

e A UNIBUS arbitrator that regulates activity on the UNI- 
BUS and assigns the memory controller to the CPU if the 
controller is not being used by a UNIBUS device. 


e A data rotating and substituting network for aligning 
memory data. Data retrieved from the arrays is always a 
32-bit longword, but the requested byte is not necessar- 
ily in the desired position. The data rotator rearranges 
the data before it is sent to the CPU or the UNIBUS de- 
vice. 


e Acontrol store that outputs 72-bit microwords that con- 
trol operations within the memory controller. 


e A microsequencer that selects the next 72-bit 
microword. 


e Two error-correcting ECC gate arrays. 
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Basic Memory Operations 

The physical address space contained in the memory con- 
troller is divided into two areas: physical memory ad- 
dresses and I/O addresses. A physical address is 24 bits, 
allowing a total address space of 16 Mbytes. 


To access this address space, the system has two types of 
operations. 


Read Operation 

In a Read operation, the physical address on the array bus 
selects the desired module and addresses the desired lo- 
cation on the module. The addressed longword and its 
seven associated check bits are retrieved and placed onto 
the array bus. 


The ECC logic takes the longword and check bits from the 
array bus and checks the longword for data errors. If a 
data error is found, ERROR is asserted to the error logic 
which then asserts ERR SUM (for a CPU operation) or UB 
ERR SUM (for a UNIBUS operation). The error is corrected 
in place and the CRD (correctable read data) bit is as- 
serted in the CSR. If the error is uncorrectable, the cycle is 
aborted and the RDS (read data substitute) bit is asserted 
in CSR1. The ECC logic returns the longword to the array 
bus for the data rotator. The data is aligned, if necessary, 
and output onto the memory control (MC) bus. 


If the operation is a CPU READ, the longword is sent to the 
CPU. If the operation is a UNIBUS device Read, the byte or 
word is transferred to the data lines of the UNIBUS. If the 
operation is a CPU Read of a UNIBUS device, the Read 
data is taken off the UNIBUS data lines, transferred to the 
MC bus via the WCS (Writable Control Store) transceivers, 
then to the data rotator, and then to the CPU. 


Write Operation 

In a CPU Write operation, Write data is placed on the MC 
bus from the CPU and then applied to the data rotator. If 
the CPU Write is to a UNIBUS device, the rotator outputs 
the data back to the MC bus. From the MC bus, the data is 
placed on the data lines of the UNIBUS. If the CPU Write is 
to the memory arrays, the rotator outputs the data onto the 
data lines of the array bus. For a UNIBUS to memory Write 
operation, Write data is placed on the MC bus, applied to 
the data rotator, and then placed onto the data lines of the 
array bus. 


The ECC logic takes the Write data off the array bus and 
uses it to generate seven ECC check bits. The data is re- 
turned to the array bus along with the check bits. The Write 
data and the associated check bits are taken from the ar- 
ray bus and written into the selected array module. 


Error Checking and Correcting 

The ECC scheme used in the memory subsystem is capa- 
ble of detecting single and double bit errors. If a single bit 
error is detected, the ECC logic can be used to correct the 
error. The logic can detect, but not correct, multibit errors. 


Each time a longword (382 bits) is written into memory, 7 
check bits are generated from the longword data and are 
stored with the longword. When the data is retrieved from 
the arrays, seven syndrome bits are generated from the 39 
retrieved bits. These seven syndrome bits indicate no 


error, a single error, or multiple errors. The single bit error 
is corrected using the seven syndrome bits and is reported 
as a CRD (correctable read data) error. 


Address Translation Buffer 

The address translation buffer contains frequently used 
virtual address translations. It significantly reduces the 
amount of time spent by the CPU on the repetitive task of 
dynamic address translation. The buffer contains 128 
virtual-to-physical page address translations: 64 system 
space translations and 64 process space translations. 
Each of these sections has parity on each entry for in- 
creased integrity. 


1-Longword Prefetch Instruction Buffer 

The 1-longword prefetch instruction buffer allows the next 
instruction to be fetched while the current instruction is ex- 
ecuting. The control logic continuously fetches data from 
memory to Keep the longword buffer full. In native mode, 
the variable length instructions are stored in contiguous 
byte positions in memory and are aligned on byte bounda- 
ries. In compatibility mode, the PDP-11 instructions are 16 
bits, occupy two contiguous bytes, and are aligned on 
word boundaries. 


Interval Timer and Time-of-Year Clock 

The VAX-11/730 processor contains an interval timer and 
a time-of-year clock. The programmable interval timer 
permits the measurement of finely resolved intervals. The 
time-of-year clock is used by VMS software to perform 
various timekeeping functions. 


VAX-11/730 UNIBUS INTERFACE 

The UNIBUS subsystem connects most medium and low 
speed peripheral devices to the VAX-11/730 system. An 
asynchronous, bidirectional bus, the UNIBUS lets the user 
select from a range of existing peripherals (those sup- 
ported by VAX/VMS and diagnostics) and also provides 
easy connection for customer-designed special devices. 
Although the UNIBUS was originally designed for im- 
plementations of the PDP-11 architecture, its capabilities 
have been expanded by the VAX architecture. Thus, exist- 
ing UNIBUS peripheral devices can be used with the new 
VAX family architecture without hardware modification. 
(UNIBUS addresses in this chapter are listed in both octal 
and hexadecimal. The PDP-11 uses octal while the VAX 
family uses hexadecimal.) 


The integral UNIBUS adapter (part of the VAX-11/730 
CPU) performs priority arbitration among devices on the 
UNIBUS, a function handled by the central processor in 
PDP-11 systems. The address translation map permits 
contiguous disk transfers to and from noncontiguous 
pages of memory (these are called scatter/gather opera- 
tions). Interrupts on the VAX-11/730 UNIBUS are directly 
vectored into the appropriate process handler. 


The UNIBUS is a communication path that links I/O de- 
vices to the UNIBUS adapter. Device addresses, data, and 
control information are passed along the 56 signal lines of 
the UNIBUS. The UNIBUS adapter handles all communi- 
cation between the UNIBUS and the system, and fields 
device-generated interrupts. 


Conceptually, the UNIBUS is designed around memory 
elements with ascending addresses starting at UNIBUS 


address zero, while registers storing I/O data or individual 
peripheral device status information have addresses in the 
highest 8 Kbytes. 


The UNIBUS adapter allows two kinds of data transfers; 
program interrupt and direct memory access (DMA). Ev- 
ery eight- or 16-bit transfer on the UNIBUS requires a 32- 
bit memory transfer (although only 16 bits are used). The 
maximum transfer rate through the direct data path is 1 
Mbytes per second. The maximum aggregate transfer rate 
through the direct data paths is 1.5 Mbytes per second. 


It should be noted that the UNIBUS adapter permits pro- 
gram interrupts, unbuffered and buffered data transfers to 
occur. 


DMF32 

The DMF82 is an intelligent VAX UNIBUS controller de- 
signed to support a combination of I/O devices. It consists 
of 1-Hex board, internal cables and cable interconnect pa- 
nel to provide the following functions: 

e Eight asynchronous lines. 

e One synchronous line. 


© One lineprinter interface or general purpose parallel I/O 
port. 


The asynchronous multiplexer portion of the DMF82 is an 
enhanced DZ11-A to provide reduced interrupt overhead 
and more functionality. Enhancements include split baud 
rate and full modem control for two channels. Other six 
channels have no modem control nor split baud rate capa- 
bility. Also, each transmit line may be programmed to run 
in either SILO or DMA mode. 


The synchronous line with full modem control is a DMA 
device that provides low level support for DDCMP, SDLC, 
and HDLC. The synchronous line knows enough about 
each protocol in order to frame messages, generate and 
check CRC, and DMA these messages to and from host 
memory. DECnet-VAX supports the DDCMP protocol of 
the DMF32. 


In addition, the DMF32 can function either as a DMA li- 
neprinter controller or a general purpose 16-bit DR11 par- 
allel interface that also features buffered or DMA transfers. 


A DMA lineprinter controller is an enhanced version of the 
LP11 controller and will control the LP11 and LP32 series 
of printers. 


Although both the lineprinter controller and the parallel in- 
terface can be attached at the same time, the user must 
physically move a hardware switch to activate one or the 
other. 


INTEGRATED DISK CONTROLLER 

An Integrated Disk Controller, the IDC, interfaces an R80 
disk drive and from one to three RLO2 disk drives to the 
system. (Up to four RLO2 drives, with no R80 drive, can 
also be interfaced.) Data transfer between the IDC and the 
CPU are over the accelerator bus and are controlled in 
part by dedicated microcode in the CPU. One 32-bit long- 
word of disk Read/Write data is transferred at a time, fol- 
lowing the generation of a microlevel (fast) processor in- 
terrupt request by the IDC. Data silos (FIFOs) in the IDC 
provide up to 1 Kbyte of data buffering for both read and 
write data. 
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In addition to connecting to the accelerator bus, the IDC 
connects to the UNIBUS for generating interrupts other 
than the fast interrupts generated for disk data transfers. 
The IDC’s UNIBUS connection also monitors the system’s 
powerfail state. 


VAX-11/730 Floating-Point Accelerator 


The Floating-Point Accelerator (FPA) is an optional proc- 
essor enhancement that operates in conjunction with the 
VAX-11/730 to execute the standard floating-point instruc- 
tion set. Floating-point representation permits a greater 
range of number values than is possible with a 32-bit in- 
teger. 


Consisting of a single module, the FPA is easily installed 
and is functionally transparent to the user. Modifications to 
hardware and software are not required for installation of 
the floating-point accelerator. 


The floating-point accelerator receives an opcode from 
the CPU and decodes the information into a starting mi- 
croaddress. The outputs of the control store ROM control 
the arithmetic operations and data path logic. 
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The floating-point accelerator executes addition, subtrac- 
tion, multiplication, and division instructions that operate 
on single-precision (32-bit), double-precision (64-bit), ex- 
tended range double-precision (64-bits), and extended 
range quadrupled-precision (128-bits) operands. It exe- 
cutes Extended Multiply (EMOD) and Polynomial Evalua- 
tion (POLY) instructions, and converts data between in- 
teger and floating-point formats and between single- 
precision and double-precision floating-point formats. The 
floating-point accelerator also executes the integer multi- 
plication instruction. 


The VAX-11/730 implements all the floating-point data 
types of VAX/VMS in the microcode and optional floating- 
point accelerator. For details on floating-point formats, re- 
fer to Table 4-1. 


The VAX-11/730 PROCESSOR 
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The VAX system supports high-performance mass storage devices for 
online data retrieval, unit record equipment for data processing, 
terminals and line interfaces for the interactive user, direct memory 
access interfaces for realtime users, and a line interface for 
interprocessor communications. 


The mass storage systems provide large capacity and high throughput. 
Each MASSBUS adapter can support up to eight disk drives or seven 
disk drives plus one magnetic-tape controller. In addition, up to eight 
medium-capacity disk drives can be connected to the system’s 
UNIBUS. VAX/VMS overlaps seeks on all multiple-drive disk 
configurations, performs multiple-block I/O transfers, and allows the 
user to control buffering, positioning, and blocking. 


Cardreaders and lineprinters can be spooled input and output devices 
managed by operator-controlled queues. The LP11 and LA11 series 
lineprinters provide a range of high-speed and low-cost printer 
models. Up to four LP11 printers and up to 16 LA11 printers can be 
used on the system. 


The DMC11 and DMP11 serial synchronous communications line 
controllers provide high-performance interprocessor connection using 
the DIGITAL Data Communications Message Protocol (DDCMP). They 
ensure reliable data transmission and relieve the host processor from 
the details of protocol operation. For very high-performance 
interprocessor communications, the VAX-11/780 offers both multiport 
memory (MA780) and a high-speed channel interface (DR780). The 
DR780 can also be used for interfacing to customer devices that 
require transfer rates of up to 6.67 Mbytes per second. 


For realtime applications, VAX supports the LPA11-K and DR11-B 
direct memory access (DMA) interfaces. These devices reduce CPU 
involvement in I/O operations and speed the transfer of data between 
external devices and computer memory. The LPA11-K is an intelligent 
(dual-microprocessor) controller that provides high-speed data 
sampling, operates in both dedicated and multirequest mode, and 
supports a number of peripheral devices. The DR11-B is a general 
purpose interface that performs high-speed block-data transfers 
between the VAX memory and user peripheral devices. 


All equipment is integrated with the software system and is supported 
by both online error logging and diagnostics. Each component includes 
extensive error-checking and -correction features. The software 
provides power failure and error recovery algorithms. 


THE PERIPHERALS 


COMPONENTS 

VAX supports four types of peripheral subsystems: 

e Mass storage peripherals such as disk and magnetic- 
tape. 

e Unit record peripherals such as lineprinters and car- 
dreaders. 


e Terminals and terminal line interfaces. 
e Interprocessor communications links. 


All peripheral device control/status registers (CSRs) are 
assigned addresses in physical I/O space. No special 
processor instructions are needed for |/O control. In addi- 
tion, all device interrupt lines are associated with locations 
that identify each device’s interrupt service routine. When 
the processor is interrupted on function request comple- 
tion, it immediately starts executing the appropriate inter- 
rupt service routine. There is no need to poll devices to 
determine which device needs service. 


Devices use either one of two types of data transfer tech- 
niques: direct memory access or programmed interrupt 
request. The mass storage disk and magnetic-tape de- 
vices and the interprocessor communications link are ca- 
pable of direct memory access (DMA) data transfers. The 
DMA devices are also called non-processor-request 
(NPR) devices because they can transfer large blocks of 
data to or from memory without processor intervention un- 
til the entire block is transferred. 


The unit record peripherals and terminal interfaces are 
called programmed interrupt request devices. These de- 
vices transfer one or two bytes at a time to or from as- 
signed locations in physical address space. Software then 
transfers the data to or from a buffer in physical memory. 


MASS STORAGE PERIPHERALS 

The mass storage peripherals include various capacity 

moving head disk drives and various speed magnetic-tape 

transports: 

e The high-performance, Winchester fixed-media tech- 
nology RM80 and R80 disk drives. 

e The high-speed, large-capacity RPO6, RPO7, and RMO5 
disk drives. 

e The high-speed, medium-capacity RMO3 disk drive. 

e The medium-speed, smaller-capacity RLO2, and RKO7 
disk drives. 

e The RX02 floppy disk. 


e The TE16, TU45, TU77, and TU78 magnetic-tape trans- 
ports. 


e The TS11 magnetic-tape transport. 


The R80, RM80, RMO03, RMO5, RPO6, and RP0O7 disks and 
the TE16, TU45, TU77, and TU78 magnetic-tape controll- 
ers are MASSBUS peripheral devices. The RX02 floppy 
disk, the RLO2, and RKO7 disk drives, and the TS11 tape 
subsystem are UNIBUS peripheral devices. Each MASS- 
BUS can support up to eight device controllers—eight disk 
controllers with one drive each or seven disk drives and 
one magnetic-tape formatter with up to eight tape trans- 
ports. 


To support the performance and reliability features of the 
system's disk and magnetic-tape devices, the operating 
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system’s disk and magnetic-tape device drivers provide: 

e Overlapped seeks for increased throughput on controll- 
ers with multiple disk drives. 

e Overlapped magtape operations (write on one transport 
while another rewinds, for example). 


e Multiple-block noncontiguous I/O transfers for file- 
structured devices. 


e Read and write checks on a per-request, per-file, and/or 
volume basis. 


e Extensive error recovery algorithms (e.g., ECC and off- 
set recovery for disk, NRZI error-correcting for 
magnetic-tape). 

e Logging of all device errors. 

e Dynamic bad-block support for file-structured disk de- 
vices. 


e Volume mount verification after a change in drive status 
(i. e., off/online, powerfail). 


e Powerfail recovery for online drives, including reposi- 
tioning of magnetic-tape transports. 


For applications requiring special data reliability checks, 
the programmer can implement user-written error recov- 
ery procedures without having to write unique device-dri- 
ver routines. The operating system driver’s normal error 
recovery retry and error logging operations can be inhi- 
bited. If any error occurs when the recovery functions are 
inhibited, the driver immediately terminates the I/O opera- 
tion and returns a failure status. User software can then 
perform its own recovery or logging procedures, since all 
the hardware diagnostic operations are available to jobs 
granted the diagnostic privilege by the system manager. 


Disks 

The disk subsystems provide high-performance and relia- 
bility. They feature accurate servopositioning, error cor- 
recting, and offset-positioning recovery. Table 5-1 
summarizes the capacities and speeds of the disk devices. 


Table 5-1 
Disk Devices 


DRIVE Capacity: Peak Ave.seek Ave. rota- 
transfer time: tional la- 
rate tency: 
(/sec): 

R80 121 MB 1.2 MB 25ms 8.33ms 

RM80 124 MB 1.2 MB 25ms 8.33ms 

RX02 512 KB 55 KB 263ms 83ms 

RLO2 10.4 MB 512 KB 55ms 12.5ms 

RK07 28 MB 538 KB 36.5ms 12.5ms 

RMO3 67 MB 1.2 MB 30ms 8.3ms 

RPO6 176 MB 806 KB 30ms 6ms 

RMO5 300 MB 1.2 MB 30ms 6.3ms 

RPO7 516 MB 2.2 MB 23ms 8.3ms 


The UNIBUS accepts RKO7, and RLO2 disk drives and the 
RX02 floppy disk. The RM80 is packaged with an associ- 
ated MASSBUS adapter in a dedicated cabinet. RM80 
subsystems are supported by the VAX/VMS operating 
system. The R80 disk drive is available as the system disk 
of a VAX-11/730 packaged system. It is interfaced to the 


processor through the Integrated Disk Controller (IDC). 
This configuration provides efficient utilization of the sys- 
tem disk while freeing the UNIBUS adapter for other I/O 
functions. 


The RX02 is the smallest-capacity disk available, while the 
RKO7 is the largest capacity UNIBUS-compatible disk. Up 
to eight RX02, RLO2, and RKO7 disk drives can be mixed in 
any combination on the same controller. In small system 
configurations where the RKO7 is used as the systems de- 
vice, two drives are required in the configuration. 


To decrease the effective access time and increase 
throughput, the operating system’s disk device drivers 
provide overlapped seeks for all disk units on a controller. 
All 1/O transfers, including write checks, are preceded bya 
seek, except when the seek is explicitly inhibited by diag- 
nostic software. On MASSBUS devices, seeks to any unit 
can be initiated at any time and do not require controller 
intervention. During seeks, the controller is free to perform 
a transfer on any unit other than the one on which the seek 
is active. If a data transfer was in progress at the time of 
completion, the driver processes the attention interrupts 
caused by seek completion when the controller is free. 


The device unit notifies the driver when it detects a read 
error that can be recovered using its error-correcting code 
(ECC). It provides the position and pattern of any error 
burst of up to 11 bits within the data field. The driver ap- 
plies the error correction to the data in memory. The trans- 
fer continues as if the error had not occurred. 


In addition to overlapping seeks with data transfers, the 
driver also overlaps offset error recovery with normal con- 
troller operation. Offset recovery enables the driver to re- 
position the head on the track to pick up a stronger signal 
on a sector during a read operation. Provided that retry is 
not inhibited, the driver performs offset recovery automati- 
cally when a read error occurs that can not be corrected 
using the hardware ECC. 


The driver logs all errors, including those from which it 
successfully recovers. The driver also supplies dynamic 
bad-block handling for virtual I/O (Files-11 file-structured) 
operations. When a bad block is detected, the information 
is stored in the file header. The bad block is recorded in 
the bad-block file when the file is deleted. 


In addition to the driver’s dynamic bad-block handling, the 


system includes an online static bad-block utility and on- 
line diagnostics for verifying drive-level functions. 


Magnetic Tape 

The TE16, TU77, and TU78 are high-performance MASS- 

BUS tape storage subsystems that share the following 

characteristics: 

© Program-selectable 1600 or 800 b/in, nine-track data 
storage for TE16 and TU77. 


® Program-selectable 1600 b/in Phase-Encoded (PE)or 
6,250 b/in Group-Encoded Recording (GCR), nine-track 
data storage for TU78. 


® Industry-compatible data formats. 

® Reading in reverse, as well as forward. 

® Parity, longitudinal, and cyclic redundancy checking. 
© NRZI error correcting. 
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The TE16 and TU77 are identical in capacity; both allow up 
to 40 Mbytes per tape reel and both allow up to eight tape 
drives per formatter. The TU78 allows up to 145 Mbytes 
per tape reel. The TU77 and TU78 offer higher speed and 
throughput. The TU77 tape-storage system can perform 
read/writes of data at the rate of 125 inches per second, 
while allowing a peak transfer rate of 200 Kbytes per sec- 
ond. The TU78 tape-storage system also performs 
read/writes of data at the rate of 125 inches/second, but 
has a peak transfer rate of up to 781 Kbytes per second. 
These features make the TU77 and TU78 ideally suited for 
heavy duty-cycle applications such as disk-to-tape backup 
and transaction processing. 


The TS11 is a medium-performance UNIBUS magnetic- 
tape subsystem containing nine tracks with a density of 1,- 
600 bits per inch. It performs read/writes at a speed of 45 
inches per second. The TS11 subsystem can handle a 
maximum data transfer rate of up to 72 Kbytes per second. 


The operating system’s magnetic-tape device driver sup- 
ports the read reverse operation that enables a program to 
request a sequential read of the block preceding the block 
at which the tape is positioned. Writing occurs only while 
the tape is moving forward. 


The operating system’s file system can read and write file- 
structured magnetic-tape volumes using the current ANSI 
magnetic-tape standard. The system also supports multi- 
volume files, program-controlled blocking factors, and un- 
labeled magnetic tapes. 


UNIT RECORD PERIPHERALS 

The operating system normally treats lineprinters and car- 
dreaders as spooled, sharable devices managed by multi- 
ple operator-controlled queues. The devices can also be 
allocated to individual programs. 


The operating system’s lineprinter handling includes line 
and page counting for job accounting. The user can 
specify carriage control as one line per record, as FOR- 
TRAN conventions, as being contained within the record it- 
self, or aS general pre-spacing and post-spacing (within 
the limits of the hardware capabilities). 


The operating system’s cardreader driver interprets the 
encoded punched information using the American Na- 
tional Standard eight-bit card code. The driver uses a spe- 
cial punch outside the data representation to indicate end 
Of file. 


LP11 Lineprinters 

LP11 series lineprinters can be connected to the VAX sys- 
tem. The LP11 series printers are impact-type rotating 
drum serial interface lineprinters. They feature full line 
buffering, a static eliminator, and a selftest capability. 


All models are 132-column printers that can accept paper 
four- to 16-3/4-inches-wide, with up to six-part forms. 
They print ten characters per inch horizontally and six or 
eight lines per inch vertically (switch-selectable). They in- 
clude a vernier adjustment for horizontal and vertical pa- 
per position. All models are available with either upper- 
case (64) or uppercase/lowercase (95) character sets 
(including numbers and symbols). Most models have op- 
tional scientific or EDP character sets. 


The low-cost models print one line every two revolutions 


(300 lines per minute with the 64-character set, 230 lines 
per minute with the 95-character set) or one line every rev- 
olution (600 lines per minute with the 64-character set, 460 
lines per minute with the 95-character set). A higher-speed 
version that includes a noise-reduction cabinet, ribbon 
guide, and a high-speed paperpuller offers 900 line-per- 
minute printing with the 64-character set or 660 line-per- 
minute printing with the 95-character set. 


For systems requiring even greater printer throughput, 
LP11 models are available that print up to 1,200 lines per 
minute with the 64-character set or 800 lines per minute 
with the 95-character set. 


The Letterprinter 100 

The Letterprinter 100 is an exceptionally versatile printer 
with user-programmable type fonts. Users can change 
type fonts (such as Courier, Gothic, Orator, etc.) or charac- 
ter sets (such as U.S., German, French, etc.) either manu- 
ally or via software host control at any time during a run. 


The Letterprinter 100 provides four printing modes: 
© Letter-quality printing at 30 characters per second. 


® Correspondence-quality printing at 80 characters per 
second. 


© High-speed draft-quality printing at 240 characters per 
second. 


@ Bit-map graphics printing. 


The Letterprinter 100 is a dot-matrix, nine-wire impact 
printer. It produces letter-quality characters by making 
multiple passes per line so the dots overlay each other to 
produce a solid character impression. It offers selectable 
horizontal character and vertical linespacing. The Letter- 
pinter’s 14-inch plate accepts roll, fanfold and cut-sheet 
paper and prints up to four-part forms. 


LA11 Lineprinter 

The LA11 is an extremely low-cost, highly reliable parallel 
interface printer. The LA11 prints at speeds up to 180 
characters per second. The print set consists of the ASCII 
characters, including 95 uppercase and lowercase letters, 
numbers, and symbols. Characters are printed using a7 X 
7 dot matrix with horizontal spacing of ten characters per 
inch and vertical spacing of six lines per inch. 


Adjustable pinfeed tractors allow for a variable-form width 
of three to 14-7/8 inches (up to 132 columns). A forms- 
length switch sets the top-of-form to any of 11 common 
lengths, with fine adjustment for accurate forms place- 
ment. The printer can accommodate multipart forms (with 
or without carbons) of up to six parts. 


CR11 Cardreader 

CR11 cardreaders can be connected to the system as pro- 
grammed interrupt request devices. The CR11 reads up to 
285 80-column punched cards per minute. The cardreader 
has a high tolerance for cards that have been nicked, 
warped, bent, or subjected to high humidity. The car- 
dreader uses a short cardpath, with only one card in the 
track at a time. It uses a vacuum pick mechanism that 
keeps cards from sticking together by blowing a stream of 
air through the bottom half-inch of cards in the input hop- 
per. The input hopper holds up to 400 cards, and cards 
can be loaded and unloaded while the reader is operating. 
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TERMINALS AND INTERFACES 

Interactive terminals can be connected to the VAX system. 
The operating system’s terminal driver provides full du- 
plex handling for both hardcopy and video terminals. 


Programs can control terminal operations through the ter- 

minal driver. The terminal driver supports many special 

operating modes for terminal lines. A program can enable 

or disable the following modes by calling a system service: 

® SLAVE — All unsolicited data are discarded. This mode 
is used to establish application-controlled terminals. 


@ NO ECHO — Data entered on the terminal keyboard are 
not printed or displayed on the terminal. This mode is 
used, for example, to read passwords typed on the ter- 
minal. 


© PASS ALL — All data entered on the terminal are trans- 
mitted to the program as eight-bit binary information 
without any interpretation, except where a line termina- 
tor or terminators are specified. This mode enables pro- 
grams to perform their own interpretation of control 
characters instead of using the VAX/VMS interpretation. 


® ESCAPE — Escape sequences entered on the terminal 
are recognized as read terminators, validated, and 
passed to a program for interpretation. 


© TERMINAL/HOST SYNCHRONIZATION — Data sent to 
the terminal are controlled by terminal-generated XOFF 
and XON. These functions are generated by typing 
CTRL/S and CTRL/Q on command terminals and are in- 
terpreted as requests to stop and resume output to the 
terminal. 


© HOST/TERMINAL SYNCHRONIZATION — All read op- 
erations are explicitly solicited with XON and terminated 
with XOFF. XON and XOFF are also used to keep the 
type-ahead buffer from filling. 


Input from a command terminal is always independent of 
concurrent output. This capability is called type-ahead. 
Data typed at the terminal are retained in a type-ahead 
buffer until a program issues a read request. At that time 
the data are transferred to the program buffer and echoed 
on the terminal (provided that echoing is not disabled). Ifa 
read is already in progress, the echo and data transfer are 
immediate. Deferring the echo until a read operation is ac- 
tive allows the program to specify the mode of the termi- 
nal, such as “No Echo” or “Convert Lowercase to Upper- 
case’, to modify the read operation. 


A line entered on a command terminal is terminated by 
any of several special characters—for example, the RE- 
TURN key. A program reading from a terminal can option- 
ally specify a particular line terminator or class of line ter- 
minators for read requests (including read PASS ALL 
requests). 


Terminal characteristics are initially established during 
system generation. Users operating command terminals 
can modify the characteristics of the particular terminal 
being used. For example, the user can set the baud rate 
(transmission speed) or change the terminal line width. 


The DECwriter I!] Pedestal-Mounted Terminal 
The DECwriter Ill is a rugged pedestal-mounted hardcopy 
terminal that offers exceptional throughput and a number 


of advanced keyboard-selectable formatting and com- 
munication features. It uses a contoured typewriter-styled 
keyboard and includes an additional numeric keypad and 
a prompting LED display for infrequently used features. 


The DECwriter Ill offers a number of features for high 
throughput: 

e 180- character-per-second print speed. 

e 14 data transmission speeds ranging up to 9,600 baud. 


e 1,024-character buffer to equalize differences between 
transmission speeds and print speeds. 


® smart and bidirectional printing so that the printhead al- 
ways takes shortest path to next print position. 


@ high-speed horizontal and vertical skipping over white 
space. 


In addition to its throughput, the DECwriter Ill is distin- 
guished by its printing features. The terminal offers eight 
font sizes, ranging from expanded (five characters per 
inch) to compressed font (16.5 characters per inch). Hence 
a user could, for example, select a font size of 16.5 charac- 
ters per inch and print 132 columns onto an 8%-inch-wide 
sheet. Other print features include six linespacings rang- 
ing from 2 to 12 lines per inch, user-selectable form 
lengths up to 14 inches, left/right and top/bottom margins, 
and horizontal and vertical tabs. 


The DECwriter Ill is designed for easy use. Terminal char- 


acteristics are selected via clearly labeled keys and simple 
mnemonic commands. Once the selections have been 
made, the operator can check the settings by depressing 
the STATUS key. The terminal will then print a listing of the 
selected settings. 


The DECwriter IV Desktop Terminal 

The DECwriter IV is a versatile low-cost microprocessor- 
controlled desktop printing terminal. It combines forms 
and paper-handling flexibility with true 30-character-per- 
second throughput. You can customize your DECwriter IV 
to meet your particular applications by chosing from a 
wide range of options. The DECwriter IV is designed so 
you can update it when your needs change. 


The DECwriter IV prints 9 x 7 dot-matrix characters. It can 
print up to 132 columns at speeds up to 30 characters per 
second. You can select frictionfeed, pinfeed, or tractors to 
handle a variety of papers — cut-sheet, roll, fanfold, or 
multipart forms with up to four parts. 


The graphics-printer version of the DECwriter IV prints 
overlapping dots to produce accurate, dense graphic im- 
ages. It can be connected to DIGITAL’s VT125 or GIGI 
video graphics terminals for making instant hardcopy of 
video graphics. 


The Correspondent Lightweight Portable Terminal 
The Correspondent is a lightweight portable terminal with 


Table 5-2 
VT100 Terminal Family 
TERMINAL WORD PROC- EDITING FEA- GRAPHICS PRINTER APPLICA- 
ESSING TURES PORTS TIONS 
VT101 NO Simple transac- 
tion processing 

VT102 VT102W Advanced Standard Communica- 
Video Standard, tions, Forms 
Line in- Management, 
sert/delete, Data Entry, 
Character in- Word Process- 
sert/delete ing (VT102W) 

VT131 Advanced Standard Communica- 
Video Standard, tions with non- 
Line in- DIGITAL sys- 
sert/delete, tems for trans- 
Character in- action process- 
sert/delete, Lo- ing 
cal editing 

VT100 VT100W Optional Ad- VT125 option Optional One of the most 
vanced Video versatile termi- 
Optional (AVO) nals ever pro- 

duced 

VT125 VT125W Advanced Bit-Map Graph- Standard Graphics, Data 

Video Standard _ ics Standard Inquiry, Report 


Writing, Word 
processing with 
business graph- 
ics (VT125W) 


heavyweight features. It prints a full 132 columns on plain 
paper and accepts multipart forms. The communications 
options include a built-in 300-baud acoustic coupler and 
an integral 1,200/300-baud direct-connect modem. 


The Correspondent prints clear crisp 9x9 dot matrix char- 
acters with true descenders and underlining at 30 charac- 
ters per second. The new user-replaceable printhead is 
built for durability. It has a 300-million-character minimum 
lifetime. 


Best of all, the Correspondent weighs less than 21 pounds, 
even when loaded with communications options. It mea- 
sures a trim 19 x 15.5 x 6 inches. The handy shoulderstrap 
carrying case is as easy to take with you as an airline carry- 
on bag. 


VT100 Family of Video Terminals 

The VT100 has evolved into an entire family of Video Ter- 
minals designed to fulfill all your interactive video terminal 
needs. The following chart will help you select the VT100 
family terminal which is best for each application. 


DZ11 Terminal Line Interface 

The DZ11 is a serial-line multiplexer whose character for- 
mats and operating speeds are programmable on a per- 
line basis. A DZ11 connects the UNIBUS with up to a 
maximum of eight or 16 asynchronous serial lines, de- 
pending on the configuration. Each line can run at any one 
of 15 speeds. 


Local operation with EIA terminals is possible at speeds up 
to 9,600 baud. Remote dialup terminals can operate full- 
duplex at speeds up to 300 baud using Bell 103 or 113 mo- 
dems or up to 1,200 baud using the Bell 212 modem. 


The DZ11 optionally generates parity on output and 
checks parity on input. Incoming characters are buffered 
using a 64-character silo buffer. Outgoing characters are 
processed on a programmed interrupt request basis. 
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DMF32 Communication Board 
11/730 UNIBUS con- 
troller designed to support a combination of !1/O devices. 
The DMF32 consists of four UNIBUS controllers on one 
hex board: 
e An 8-line asynchronous multiplexer featuring pro- 
grammed DMA mode transmit lines. 


e A DMA synchronous line supported by DECnet com- 
munications software. 


e And either a DMA lineprinter controller. 


e Ora general purpose 16-bit DR11 parallel interface that 
also features buffer or DMA transfers. 


The DMF82 is programmed for 3 interfaces to run concur- 
rently; the asynchronous multiplexer, synchronous 
multiplexer, and LP or DR device. 


The asynchronous multiplexer contains eight transmit and 
eight receive lines. Each pair of lines can be programmed 
to operate at one of 15 baud rates ranging from 50 baud to 
9,600 baud. Two of the eight lines are equipped with both 
split-speed capability and modem control. Transmission 
can be selected for DMA or SILO operation. The two 
modes of output allow optimization by the terminal handler 
dependent on message length. The asynchronous lines 
are connected to data terminal equipment (DTE) or data 
communications equipment (DCE) via standard EIA 
RS232-C 25 pin connectors located on panel. 


The synchronous interface is a single-line full-modem pro- 
gram-controlled DMA communications device. The DMA 
transfers are double-buffered and, therefore, both the 
transmitter and the receiver have two sets of byte-count 
and buffer-address registers. The double-buffering 
scheme results in high message throughput. The synchro- 
nous protocols built into DMF32 microcode are basic bit- 
stuff SDLC, HDLC, and bytecount DDCMP. The synchro- 
nous line knows enough about each protocol in order to 
frame the message, generate and check CRC, and DMA 
these messages to and from host memory. All message 
acknowledgements and higher-level network functions are 
performed by host-level software. 


The connection to the single line conforms to EIA RS232- 
C/CCITT V.28 for speeds up to 19.2K baud. However, the 
maximum operating speed is 56K baud. 


The /ineprinter interface operates with LP11 model print- 
ers, but in DMA. Additional features such as Forms Con- 
trol DAVFU and low-level formating functions are possible, 
provided the printer unit and host software support the 
same features. 


The 16 bit Parallel Interface is an enhanced version of the 
DR11-C. It is compatible with the DR11-C, but can also 
support SILO mode via 32-character Word Silo half-du- 
plex or double-buffered DMA transfer in half duplex. 
These new features result in reduced interrupt overhead 
and high throughput. The parallel interface shares hard- 
ware with the lineprinter interface; therefore, both cannot 
be used concurrently. 


REALTIME I/O DEVICES 
To enhance realtime performance, VAX supports the DR- 
11B, the LPA11-K direct memory access (DMA) interfaces, 


and the DR780 32-bit high-performance parallel interface 
(VAX/11-780 only). These devices allow data to be trans- 
ferred from a peripheral device to memory and vice versa 
without the intervention of computer programs, except at 
the initialization and completion of transfers. The result is 
that CPU involvement in I/O operations is greatly reduced. 
Further, since these devices are capable of “driving” large 
blocks of information at high speeds, their usage can 
greatly increase I/O bandwidth, that is, the capacity of the 
system to sustain a total data transfer load. I/O bandwidth 
is an important performance measure in realtime applica- 
tions, since such applications require data transfers 
between external devices and computer memory. 


LPA11-K 

The LPA11-K is an intelligent (dual-microprocessor) direct 
memory access controller that buffers realtime data and 
transfers them to VAX memory in efficient blocks (rather 
than a word at a time). Since the LPA11-K has automatic 
buffer-switching capability, transfers can occur continu- 
ously. Via a system call, the programmer can instruct the 
LPA11-K to take samples from a data source at specified 
time intervals. Sampling is handled by the microproces- 
sors, without the intefvention of the CPU. 


The LPA11-K operates in two distinct modes: dedicated 
mode and multirequest mode. 


In multirequest mode, up to eight requests can be active 
concurrently. Each user’s sampling rate is a user-specified 
multiple of the common realtime clock rate; thus, indepen- 
dent rates can be maintained for each user. Each request 
specifies the device so that analog-to-digital, digital-to-an- 
alog or digital |/O can be synchronously sampled; the tran- 
sition of a bit in a digital word can synchronize the 
sampling with a user event. In multirequest mode, 
throughput is determined by the number and types of re- 
quests. The aggregate throughput rate for all users is typi- 
cally 15,000 samples per second. 


In dedicated mode, one user can sample from analog-to- 
digital converters, or output to a digital-to-analog 
converter. Two analog-to-digital converters can be con- 
trolled simultaneously. Sampling is initiated by an overflow 
of the realtime clock, or by an external signal. Two sam- 
pling algorithms are implemented. One — at each overflow 
— samples both analog-to-digital converters in parallel, 
allowing two channels to be sampled simultaneously. The 
other algorithm samples the two converters on an inter- 
leaved basis, beginning with the first whose sampling be- 
gins on alternate clock overflows. 


The LPA11-K supports the following I/O devices on VAX: 
® AA11K (four-channel 12-bit D/A converter). 

® AD11K (eight-channel 12-bit A/D converter). 

© AM11K (multiplexer board). 

® DR11K (16-bit parallel, general device interface). 

® KW11K (realtime clock). 


DR11-B 

The DR11-B is a general purpose direct memory access 
(DMA) digital interface to the UNIBUS. The DR11-B, rather 
than using programmed controlled data transfers, oper- 
ates directly to or from memory, moving data between the 
UNIBUS and the user device. The DR11-B, like the LPA11- 
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K, is a block-transfer device. However, it is less expensive 
than the LPA11-K, does not include a microprocessor, and 
can only handle a single task for a single programmer. 


The DR11-B interface consists of four registers: command 
status, word-count, bus-address, and data. Operation is 
initialized under program control by loading word count 
with the two’s complement of the number of transfers, 
specifying the initial memory or bus address where the 
block transfer is to begin and by loading the com- 

mand/status register with function bits. The user device 
recognizes these function bits and responds by setting up 
the control inputs. If the user device requests data from 
memory of a UNIBUS device, the DR11-B performs a UNI- 
BUS Data In transfer (DATI) and loads its data register with 
the information held at the referenced bus address. The 
outputs of this register are available to the user device; this 
output data is buffered. If the user device requests data to 
be written into memory, the DR11-B performs a UNIBUS 
Data Out transfer (DATO), moving data from the user de- 
vice to the referenced bus address; this input data is not 
buffered. Transfers normally continue at a user-defined 
rate until the specified number of words is transferred. The 
DR11-B has the capability of transferring data at a rate of 
500,000 bytes per second, but actual transfer rates de- 
pend upon the particular configuration. 


DR780 

The DR780 is a high-performance general purpose inter- 
face adaptor that enables users to directly interface cus- 
tom devices to a VAX-11/780 system or to connect two 
VAX-11/780 systems. This high-performance, general 
purpose interface provides a 32-bit parallel data path ca- 
pable of transferring data at up to 6.67 Mbytes per second. 


The architecture of the DR780 uses separate interconnect 
structures for transfer of control information and data. The 
control interconnect is an asynchronous eight-bit bidirec- 
tional path for transferring control information to and from 
the user device. The eight--bit width of the control inter- 
connect makes it possible to have up to 256 individual 
registers in the user device. The data interconnect is a syn- 
chronous 32-bit bidirectional path synchronized to a single 
clock (either the internal DR780 clock or a clock provided 
in the user device). By using the DR780 internal clock, the 
transfer rate is selectable under program control from 156 
Kbytes to 6.67 Mbytes per second. 


The DR780 provides the high-performance interface to uti- 
lize the system bandwidth of the VAX-11/780. However, to 
achieve DR780 bandwidths over 2.0 Mbytes per second, it 
is required that the system include two interleaved mem- 
ory controllers. 


Typical applications of the DR780 are high-speed data 
collection, CPU-to-CPU communications, signal process- 
ing, and interfacing to graphics and array processors. 


INTERPROCESSOR COMMUNICATIONS LINK 
VAX permits interprocessor communications via the 
DMC11 and DMP11 communications links or via the 
MA780 multiport (shared) memory. The MA/780 is sup- 
ported by the VAX-11/780 processor only. 


Synchronous Line Controllers 

The DMC11 communications link is designed for high-per- 
formance point-to-point serial interprocessor connection. 
The DMP11 allows multipoint or point-to-point operations 
over common-carrier lines and private lines or through 
shielded cable. Both line controllers ensure maximum 
throughput with minimum processor intervention by Read- 
Only-Memory (ROM) implementation of the DIGITAL Data 
Communications Message Protocol (DDCMP). 


When the DMP11 is used for multipoint operation, the con- 
trol computer station (master) can downline load and start 
programs at the tributary (slave) stations. 


By implementing the DDCMP protocol in their high-speed 
microprocessor, the DMC11 and DMP11 ensure reliable 
data transmission and relieve the host processor of the de- 
tails of protocol operation (including character and mes- 
sage synchronization, header and message formatting, er- 
ror checking, and retransmission control). The DDCMP 
protocol detects errors on the channel interconnecting the 
system using a 16-bit Cyclic Redundancy Check (CRC-16). 
Errors are corrected by automatic retransmission. Se- 
quence numbers in message headers ensure that mes- 
sages are delivered in proper order with no omissions or 
duplications. 


The DMC11 and the DMP11 support full- or half-duplex 
operation. Full-duplex operation offers the highest 
throughput and is used when the communications facilities 
permit two-way operation. The DDCMP protocol permits 
continuous simultaneous transmission of data messages 
in both directions when buffers are available and there are 
no errors on the channels. 


If both computers are located in the same facility, the 
DMC11 and DMP11 permit transmission at speeds of up to 
1 Mbit per second over coaxial cable up to 6,000 feet long, 
or speeds of up to 56 Kbits per second over coaxial cable 
up to 18,000 feet long. The necessary modems for local in- 
terconnection are built in. 


For remote and connections using common-carrier facili- 
ties, the DMC11 and DMP11 permit transmission of up to 
19,200 bits per second using synchronous modems con- 
forming to the EIA RS232-C or the CCITT V.24/V.28 
standard. The DMP11 can transmit up to 56 Kbits per sec- 
ond when connected to a synchronous modem conform- 
ing to the EIA RS423-A or the CCITT V.35 DDS standard. 


MA780 Multiport Memory 

MA780 multiport memory is a bank of MOS semiconduc- 
tor memory with error-correcting code (ECC) that can be 
shared by up to four VAX-11/780 systems. Each system 
can randomly access all of the shared memory in exactly 
the same way it accesses its local memory. 


Each MA780 can be expanded from a minimum of 256 
Kbytes to a maximum of two Mbytes. This storage is in ad- 
dition to each system's local memory, which can be as 
large as eight-Mbytes. Since there can be up to two 
MA780s connected to a CPU, a VAX-11/780 system can 
now directly address up to 12 Mbytes of physical memory. 


Extensions to VAX/VMS make access to the shared mem- 
ory transparent to the programmer. That is, processes can 
be moved from one CPU to another with transparency to 
the programs involved. 
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The MA780 can be thought of as a very fast communica- 
tion device between VAX-11/780 systems. Specifically, 
VAX/VMS provides support for interprocessor communi- 
cations through the sharing of data regions, VMS mail- 
boxes, and common event flags. VAX/VMS also allows 
code to be shared among CPUs. 


The MA780 can be used to configure multiple computer 
systems for very high throughput. Depending on the appili- 
cation, the CPUs can be arranged in either a parallel or 
pipeline manner, as described in Figure 5-1 below: 


OUTPUT 


PARALLEL 


PIPELINE 


Figure 5-1 
Multiported Memory Configurations 


In parallel systems, two or more appropriately pro- 

grammed CPUs can divide a task. This allows the CPUs to 
effectively pool their power to finish the job quickly. Pipe- 
line systems can increase throughput by allowing instan- 
taneous data exchange between CPUs that are handling 
sequential parts of an application. 


CONSOLE STORAGE DEVICES 

The VAX-11/780 console utilizes the RX0O1 floppy disk 
while the VAX-11/730 and VAX-11/750 consoles utilize the 
TU58 magnetic-tape cartridge. 


RX01 Floppy Disk Cartridge 

The RX01 floppy disk is an integral part of the VAX-11/780 
console subsystem, storing microdiagnostics and system 
software. This feature facilitates fast diagnosis (initiated 
both locally and remotely), simplifies bootstrapping and 
initialization, and improves software-update distribution. 


The RX01 is a random access mass memory subsystem 
that stores data in fixed-length blocks on a flexible diskette 
with preformatted, industry-standard headers. The RX01 
is a single-drive floppy capable of storing 256 Kbytes of 
data. The RX02 floppy disk system can also read/write 
data formatted for the RX01 floppy disk. 


TU58 tape cartridge 

The TU58 Tape Cartridge Drive is an important part of the 
VAX-11/730 and VAX-11/750 console subsystems. Be- 
cause the TU58 is connected directly to the CPU, it main- 
tains the capability to administer diagnostics even with 
some system components inoperative. This feature signifi- 
cantly increases system reliability. The TU58 can also be 
used to boot the system, to load files into physical mem- 
ory, and to store files that describe and execute site-spe- 
cific bootstrap procedures. 


The tape cartridge is preformatted to store 2,048 records, 
each containing 128 bytes. The controller provides 
random access to any record. The TU58 searches at 60 
inches per second to find the file requested, then reads at 
30 inches per second. Data read from the tape are verified 
through checksums at the end of each record or header. 
All data transfers between the TU58 and the host are in 
512-byte blocks, with the TU58 concatenating four 128- 
byte records to accomplish this. Data are transferred to 
the CPU at approximately two Kbytes per second. 
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VAX/VMS is the general purpose operating system for VAX systems. It 
provides a reliable high-performance environment for the concurrent 
execution of multiuser timesharing, batch, and realtime applications. 
VAX/VMS provides: 

e Virtual memory management for the execution of large programs. 

e Event-driven priority scheduling. 


e Shared memory, file, and interprocess communication data 
protection, based on ownership and application groups. 


e Programmed system services for process and subprocess control 
and interprocess communication. 


VAX/VMS uses memory management features to provide swapping, 
paging, and protection and sharing of both code and data. Memory is 
allocated dynamically. Applications can control the amount of physical 
memory allocated to executing processes, the protection pages, and 
swapping. These controls can be added after the application is 
implemented. 


VAX/VMS schedules CPU time and memory residency ona 
preemptive priority basis. Thus, realtime processes do not have to 
compete with lower-priority processes for scheduling services. 
Scheduling rotates among processes of the same priority. 


VAX/VMS allows realtime applications to control their virtual memory 
paging and execution priority. Realtime applications can eliminate 
services not needed to reduce system overhead. Processes granted 
the privilege to execute at realtime scheduling levels, however, do not 
necessarily have the privilege to access protected memory and/or data 
structures. 


VAX/VMS includes system services to control processes and process 
execution, control realtime response, control scheduling, and obtain 
information. Process control services allow the creation of 
subprocesses as well as independent detached processes. Processes 
can communicate and synchronize using mailboxes, lock management 
services, shared areas of memory, shared files, or multiple common 
event flag clusters. A group of processes can also communicate using 
multiported memory. 


Applications designers can use the VAX/VMS protection and privilege 
mechanisms to implement system security and privacy. VAX/VMS 
provides memory access protection both between and within 
processes. Each process has its own independent virtual address 
space that can be mapped to private pages or shared pages. A process 
cannot access any other process’s private pages. VAX/VMS uses the 
four processor access modes to read and/or write protect individual 
pages within a process. Protection of shared pages of memory, files, 
and interprocess communication facilities, such as mailboxes and 
event flags, is based on User Identification Codes individually assigned 
to accessors and data. 


INTRODUCTION 

VAX/VMS is built for executing high-performance applica- 

tions wherein: 

e Event-driven interprocess communication and pro- 
cedure and data sharing are important. Order entry and 
teller transaction systems often consist of many cooper- 
ating processes that synchronize record creation and 
modification. 


e Priorities of resource allocation can be set for currently 
executing jobs. Both realtime processes and resource- 
sharing processes can execute in the same environ- 
ment, asin a communications network. High-speed 
links can be serviced on demand, while interactive ter- 
minal users and batch jobs share processor time and 
peripherals. 


e Large programs can be developed to execute in a physi- 
cal memory smaller than the program’s total memory re- 
quirements. Engineering computation programs such 
as simulators often build data arrays that require a large 
address space to describe the arrays. 


The VAX/VMS operating system provides the runtime ser- 
vices for executing high-performance application systems. 
Operations managers and systems programmers have 
considerable flexibility in designing and controlling data 
and program flow. 


Applications can be divided into several independent sub- 
systems in which data and code are protected from one 
another and yet still have general communication and data 
sharing facilities. Jobs can communicate using general, 
group, or local communication facilities. 


Applications which require an immediate response to 
some external event can be scheduled as realtime 
processes. When a realtime process is ready to execute, it 
executes until it becomes blocked or another higher-pri- 
ority realtime process needs the resources of the proces- 
sor. Normal jobs can be scheduled using a modified 
preemptive algorithm that ensures they receive processor 
and peripheral resources at regular intervals, commensu- 
rate with their processing needs. 


If insufficient memory is available for keeping concurrently 
executing jobs resident, the operating system will swap 
jobs in and out of memory to allocate each its share of 
processor time. Realtime processes can be locked in 
memory to ensure that they can be started up rapidly when 
they need to execute. 


The operating system provides a dynamic virtual memory 
programming environment. Large programs can be exe- 
cuted in a portion of physical memory that is considerably 
smaller than the program’s memory requirements, without 
requiring the programmer to define overlays. The operat- 
ing system optimizes its virtual memory system for pro- 
gram locality and provides tools that support optimization. 
It makes program performance predictable and 
controllable by allowing the programmer to restrict physi- 
cal memory usage and by bringing in large amounts of a 
program at one time. Processes executing under 
VAX/VMS page against themselves, not against the entire 
system; thus, heavily paging processes executing large 
programs do not affect the paging of other processes. 
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The operating system provides sophisticated peripheral 
device management for sharing, protection, and through- 
put. Devices can be shared among all jobs or reserved for 
exclusive use by particular jobs. Input and output for low- 
speed devices are spooled to high-speed devices, to in- 
crease throughput. Files on mass storage devices can be 
protected from unauthorized access on an individual, 
group, or volume basis. 


Furthermore, the |/O-request-processing system is optim- 
ized for throughput and interrupt response. The operating 
system provides the programmer with several data ac- 
cessing methods — from logical record accessing for easy 
device-independent programming to direct I/O accessing 
for extremely rapid data processing. Files can be stored in 
any of several ways to optimize subsequent processing. 


VAX/VMS provides the programming tools, scheduling 
services, and protection mechanisms for multiuser pro- 
gram development. Programmers can write, execute, and 
debug programs on the system interactively and can also 
create batch command files that perform repetitive pro- 
gram development operations without requiring their at- 
tention. 


Although it provides a multiuser program development 
environment, VAX/VMS is unlike traditional program-de- 
velopment timesharing systems. VAX/VMS is an applica- 
tion-oriented operating system that optimizes total system 
throughput and response to high-priority activities. Asina 
timesharing system, interactive jobs can be given equal 
opportunities for resource acquisition. In addition, the sys- 
tem can be executing realtime applications while program 
development jobs run, since higher-priority activities al- 
ways have the ability to preempt lower-priority activities. 


COMPONENTS AND SERVICES 

The operating system is the collection of software that or- 
ganizes the processor and peripherals into a high- 
performance system. The operating system’s basic com- 
ponents include: 


e Processes that control initial resource allocation, com- 
municate with the system operator, and log errors. 


The command interpreters. 

User-callable process control services. 
Memory management routines. 

Shared runtime library routines. 

Scheduling routines and swapper. 

File and record management services. 
Interrupt and I/O processing routines. 
Compatibility-mode executive routines. 
Hardware and software exception dispatching. 


The operating system’s jobs run as independent activities 
on the system. They include the Job Controller, which initi- 
ates and terminates user processes and manages 
spooling; the Operator Communications Manager, which 
handles messages queued to the system operators; the 
Swapper, which controls the swapping of a processes 
working set in and out of main memory; and the Error Log- 
ger, which collects all hardware and software errors de- 
tected by the processor and operating system. 


A command interpreter executes as a service for interac- 
tive and batch jobs. It enables the general user to request 
the basic functions that the operating system provides, 
such as program-development, file management, and sys- 
tem information services. 


Both hardware-detected and software-detected exception 
conditions are tracked through the exception dispatcher. 
The exception dispatcher passes control to user-pro- 
grammed condition handlers or, in the case of systemwide 
exception conditions, to operating system condition 
handlers. 


The operating system’s memory management routines in- 
clude the image activator, which controls the mapping of 
virtual memory to system and user jobs; the pager, which 
moves portions of a process in and out of memory as re- 
quired; and various system services that are callable by 
users who want to manage their virtual address space 
directly. These respond to a program’s dynamic memory 
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requirements and enable programs to control their allo- 
cated memory, share data and code, and protect them- 
selves from one another. 


The scheduler controls the allocation of processor time to 
system and user jobs. The scheduler always ensures that 
the highest-priority ready-to-execute realtime process re- 
ceives control of the processor until it relinquishes it. 
When no realtime processes are ready to execute, the 
scheduler dynamically allocates processor time to all other 
jobs according to their priorities and resource require- 
ments. The swapper works in conjunction with the schedu- 
ler to move entire jobs in and out of memory when memory 
requirements exceed memory resources. The swapper 
ensures that the jobs most likely to execute are kept in 
memory. 


The operating system’s |/O-processing software includes 
interrupt service routines, device-dependent I/O drivers, 
device-independent control routines, and user-pro- 
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Figure 6-1 
Programs and Processes 
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grammed record-processing services. The I/O system en- 
sures rapid interrupt response and processing through- 
put, and provides programming interfaces for both special 
purpose and general purpose I/O processing. 


The next few sections discuss some of the concepts basic 
to understanding the operating system’s functions and 
services. They are followed by descriptions of the services 
available to individual and cooperating processes and de- 
scriptions of memory management and scheduling for the 
systems programmer. 


PROCESSING CONCEPTS 

To support high-performance multiprogramming applica- 
tion environments, the operating system provides the ap- 
plications programmer with the tools to implement: 

e Shared programs. 

e Shared files and data. 


e Interprocess communication and control. 


To enable the programmer to write shared programs 
easily, the operating system treats a program indepen- 
dently of the context in which a program executes. The 
context defines the privileges assigned by the system 
manager to a particular user. Users with different privi- 
leges can share programs, and the operating system will 
enforce protection independently of the program. 


The operating system controls privileges and accounts for 
resource allocation by job. A job can be performing proc- 
essing operations under the direction of one user at a ter- 
minal or it can be performing processing operations for 
several users at a number of different terminals. A job can 
consist of one or several independently executing 
processes that share the resource allocations for that job. 
Jobs can be grouped into application subsystems that 
share files and communication channels that are pro- 
tected from other application subsystems. 


Programs and Processes 

The four concepts important for understanding how the 
operating system supports multiprogrammed application 
systems are: 

e /mage, or executable program. 

e Process, or image context and address space. 

e Job, or detached process and its subprocesses. 

© Group, or set of jobs that can share resources. 


These concepts are, for the most part, transparent to the 
general user whose only contact with the system is the op- 
erating system’s command-language interpreter or an ap- 
plication’s command interface. They are, however, signifi- 
cant concepts for the applications programmer. Figure 6-1 
illustrates the concepts of groups, jobs, processes, and 
images. 


An image is an executable program. It is created by trans- 
lating source-language modules into object modules and 
linking the object modules together. An image is stored in 
a file ondisk. When a user runs an image, the operating 
system reads the image file into memory to execute the 
image. 
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The environment in which an image executes is its context. 
The complete context of an image not only includes the 
state of its execution at any one time (known as its hard- 
ware context), but also includes the definition of its re- 
source allocation quotas, such as device ownership, file 
access, and maximum physical memory allocation. The 
resource allocation quotas are determined by the quotas 
given to the user who runs the image. 


Two or more users can execute the same image concur- 
rently; that is, image code can be shared, in which case the 
image is executing in two or more different contexts. An 
image context, including the address space used by an im- 
age, is called a process. The operating system schedules 
processes, and a process provides a context in which an 
image executes. 


The distinction between an image and a process is signifi- 
cant. We can speak of two processes, each executing the 
FORTRAN compiler. There may be only one copy in 
physical memory of the FORTRAN compiler’s image, but 
two different contexts in which the image executes. In one 
context, the compilation may have just begun; in the other 
context, it may be almost complete. In one context, the 
compiler may be reading and writing files listed in one 
directory; in the other context, the compiler may be read- 
ing and writing files listed in another directory. 


A process executes only one image ata time, but provides 
the context for serially executing any number of different 
images. For example, when a user logs on the system at an 
interactive terminal, the operating system creates a proc- 
ess for that user. If the user edits a file, the editor image 
executes in the context of that user’s process. If the user 
then compiles a program, the compiler image executes in 
the context of that user’s process. A process thus acts as a 
continuous “envelope” for a user’s activities. 


An image executing in the context of a process can create 
subprocesses. A subprocess can be thought of as an aux- 
iliary process in which a given image executes. When an 
image creates a subprocess, it identifies the image to be 
executed in the context of the subprocess or the source of 
commands to be interpreted in that process. An image 
executing in a subprocess context can in turn create other 
subprocesses. 


The process executing the image that creates a subpro- 
cess is an owner process. An owner process has complete 
control over the execution of the subprocesses it creates. 
It determines which of its privileges it will allow a subpro- 
cess to have. Each detached process and all sub- 
processes created below it heirarchically share a common 
pool of quotas. The owner process can control the 
scheduling of its subprocess and can delete the subpro- 
cess. When an owner process terminates, all of the sub- 
processes it owns are terminated. 


A detached process is the process created by the operat- 
ing system on behalf of a user who logs onto the system 
and requests services of the system using a command 
interpreter. A detached process has no owner. Normally, 
only the operating system can create detached processes, 
but a suitably privileged application program could also 
create a detached process and start up an application 
command interface to execute images serially for the de- 
tached process or any subprocess it creates. 


A job consists of a detached process, all the subprocesses 
it creates, and all the subprocesses they create, etc. Jobs 
are the accounting entities that the system uses to control 
resource allocation. All processes constituting a job are 
scheduled independently (they can compete for processor 
time individually to overlap processing), but they share the 
total resources allocated to the detached process. Each 
job has a set of resources that it can use, that is, author- 
ized quotas. Subprocesses share these quotas with the 
detached process. 


Jobs can be associated in groups. Groups are the basis for 
the definition and development of application subsystems. 
Groups are mutually exclusive; that is, if a job belongs to 
one group, it does not belong to any other group. A proc- 
ess with appropriate privilege can control the execution of 
other processes in the same group. Processes in the same 
group can synchronize their activities, using protected 
group communication facilities. 


Resource Allocation 

The resources of the system are the processor, memory, 
and peripherals. The system handles many jobs simulta- 
neously, and each job can have different resource require- 
ments. The operating system enables jobs to share the re- 
sources according to their individual needs, and the 
operating system protects each job and its data from other 
jobs on the system. 

The operating system controls resource allocation dy- 
namically through its scheduling, memory management, 
device allocation, and |/O-processing software — and 
statically through the authorization of users. 

The system manager is responsible for creating an au- 
thorization file entry for each user of the system. The au- 
thorization file provides the operating system with the re- 
source quotas and limits for each job. For example, there 
are quotas and limits that control: 

e Total processor time usage. 

e Number of subprocesses a job can create. 

e Number of simultaneously open files. 

e Process virtual and physical memory usage. 

e Number of simultaneous I/O transfers. 


Separate authorization files located on each disk volume 
control disk usage quotas. 


Privileges 

In addition to providing job quotas, the user authorization 

file provides the base definition for each user’s privileges. 

There are potentially 64 distinct privileges that can be 

individually granted or withheld. Among them are privi- 

leges that give the job the right to: 

e Alter the priority of a process. 

e Execute a user-written program at a more-privileged ac- 
cess mode. 

® Execute operator functions. 

e Create detached processes. 


e Set up the communication facilities used by cooperating 
processes. 


e Control other processes in the same group. 
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Whenever the user executes an image, the image can, at 
most, acquire only those privileges and quotas granted 
directly to that user’s job by the authorization file, unless 
the image is a known image. Known images are installed 
by the system manager, and while they execute they pro- 
vide a second dynamic set of privileges granted a user. 


When the user executes a known image, the process has 
the privileges and quotas granted to the user in the au- 
thorization file p/us those run time execution privileges 
granted specifically to that image. While that image exe- 
cutes, the user may have the privilege to perform opera- 
tions not granted when executing any other image. For ex- 
ample, one known image is the operating system’s LOGIN 
image, which enables a user to log on the system. The 
LOGIN image has the privilege required to access the user 
authorization file to obtain the user’s privileges and quo- 
tas. 


Protection 

The basis for data protection in the VAX system is the user 
identification code (UIC). A UIC consists of two numbers: a 
group number and a member number. The system man- 
ager assigns each user a user identification code (UIC) in 
the user authorization file. Images that the user executes 
are given or denied data access privileges based upon the 
user's UIC. 


When a file or an interprocess communication facility is 
created, it is assigned a UIC and a protection code. The 
UIC determines which group of users or programs and 
which members within the group have controlled access to 
that data. The protection code provides the access control. 


The protection code applies to four types of access: read, 

write, execute, and delete. Each type of access can be 

given or denied to: 

e The owner — the user whose UIC is the same as the UIC 
assigned to the data. 


e The group — every user whose UIC group number is the 
same as that assigned the data. 


e The world — every user whose UIC group number is dif- 
ferent or the same from that assigned the data (every- 
one on the system). 


e The system — every user or program with the privilege 
SYSPRV and those whose UIC group number is a sys- 
tem privileged group number (1-X, where X is a number 
specified by the sysgen parameter, MAXSYSGROUP). 


For example, in a common application of the protection 

scheme, a user can create a program image file and as- 

sign it the same UIC as the user’s own UIC (the default 

case). The user can give it a protection code to: 

e Enable the user (and all other users with the same UIC) 
to read, write, execute, and delete the file. 


e Enable other users in the group to execute the program 
image, but prevent them from reading, writing, or delet- 
ing the file. 

e Prevent all users outside the group (other than privi- 
leged system users) from reading, writing, executing, or 
deleting the file. 


@ Enable the the privileged system users to read the file 
(so that it can be backed up, for example). 


Read and write access applies to both files and interpro- 
cess communication facilities. Delete access applies only 
to files, and execute access applies only to program- 
image files. (The privileges and quotas granted in the user 
authorization file control creation and deletion for interpro- 
cess communication facilities.) 


USER PROCESS ENVIRONMENT 


and request special processing services from the operat- 
ing system. The following paragraphs introduce program 
virtual address allocation and the fundamental system ser- 
vice procedures available to user programs directly, as 
well as indirectly through the more complex programmed 
requests provided by the operating system. 


Virtual Address Space Allocation 


Process virtual address space is the set of 32-bit ad- 
dresses that an image executing in the context of a proc- 
ess uses to identify byte locations in virtual memory. For 
the purpose of allocating virtual memory to processes, the 
operating system divides process virtual address space 
into four sets of virtual addresses. The first three sets of 


The user program environment is the process, which is the 
entity the operating system schedules for execution. Each 
process has its own independent address space in which 
an image executes. Each image executing in a process 
can call system service procedures to acquire resources 
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Figure 6-2 
Virtual Address Space Allocation 
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addresses are called the program region, the control re- 
gion, and the system region. The fourth set of addresses is 
unused. 


Figure 6-2 illustrates the general allocation of virtual ad- 
dress space for each process. Addresses in the first two 
regions are used for process code and data: the first re- 
gion is generally used for image-specific code and data 
and the second region for stacks, process-permanent 
data, buffers, and operating-system code. Addresses in 
the system region are also used for code and data main- 
tained by the operating system; but, in this case, the ad- 
dresses refer to the same locations in every process con- 
text. The system region addresses provide a set of 
locations whose addresses are independent of process 
context and, therefore, do not have to be context- 
switched. 


When a user program is translated and linked, the image 
is allocated addresses starting with address 512 and con- 
tinuing up. The first page is not normally allocated (al- 
though it can be) because it helps catch programming er- 
rors caused by improperly initialized pointers, by 
branching or jumping to zero, or by passing zero or other 
small addresses as arguments. The linker allocates the re- 
mainder of address space to image sections according to 
whether they are shared or private, position-independent 
or position-dependent, and read-only or read/write, such 
that memory protection can be used to full advantage in 
preventing and isolating programming errors. 


The addresses in the control region are used to identify the 
locations containing temporary image control information 
and data such as the stacks, permanent-process control 
information (like as I/O channel allocations), and code 
provided by the operating system. These addresses are al- 
located from address 23! ° down. One reason this 
method of allocating in reverse is convenient is because 
the control region contains the process stacks; stacks 
grow to lower addresses as data are added and to higher 
addresses as data are removed. 


There are four stack areas reserved in the control region, 
one for each access mode protection level that the proces- 
sor provides for software executing in the context of a 
process. (Refer to the VAX Processors section for a de- 
scription of access modes.) The stack seen by the image 
executing in the program region is the user stack. All other 
stack areas are protected from that image. These stacks 
are used by operating system software executing in the 
context of the process on behalf of the image the process 
is executing. For example, command interpreters use the 
supervisor stack, the record management services use the 
executive stack, and the exception dispatcher and some 
exception handlers use the kernel stack. 


The system region addresses, which start at address 2°", 
are used to identify the locations containing the entry vec- 
tors for system-service procedures, followed by locations 
containing privileged operating system code and data. The 
system-service entry vectors are permanently reserved 
virtual addresses so that no relinking is required if system 
services are modified. Other addresses in the system re- 
gion are not generally used by the image allocated to the 
program region, and access to areas mapped by these ad- 
dresses is restricted. 
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System Services 

An image requests services of the operating system 
directly through calls to the system services. The system 
services are to the operating system what the instruction 
set is to the processor. They provide all the primary re- 
source-request activities, such as I/O processing and in- 
terprocess communication. Other programmed requests 
available to the user are often derived from system ser- 
vices. For example, the record management services use 
the I/O processing system services as the basis for logical- 
record-processing functions. 


Images that use the system services can be written in as- 
sembly language or any native programming language 
that has a CALL statement. (Refer to the Languages sec- 
tion and the section on the RSX-11M Programming Envi- 
ronment for system services available for compatibility- 
mode programming languages.) The CALL interface is the 
same, independent ofthe programming language se- 

lected, with the exception of CORAL 66. 


Table 6-1 summarizes the system services available to the 
applications programmer, some of which are controlled by 
privilege. The table also lists those system services used 
primarily by the operating system, but which can also be 
used by suitably privileged application system code. 


1/O System Services 

The operating system provides the programmer with two 
request interfaces for performing input/output operations: 
the I/O system services and the record management ser- 
vices. Record management services, discussed in the In- 
formation Management Facilities section, provides a 
general purpose file- and record-programming interface 
that satisfies most I/O processing needs and allows the 
programmer to implement I/O processing quickly. The I/O 
system services provide the programmer with direct con- 
trol over the |/O-processing resources of the operating 
system. In particular, the I/O system services enable the 
programmer to: 

e Perform both device-independent and device-depen- 

dent I/O processing. 


e Read and write blocks on mass storage media using 
physical (device-oriented), logical (volume-relative), or 
virtual (file-relative) addressing. 


The I/O system recognizes several types of devices, and 
— within the extents of their capabilities — all devices are 
programmed in the same manner. All devices can be se- 
quentially accessed, including such mass storage devices 
as disks and magnetic tapes and record-oriented devices 
such as terminals, cardreaders and lineprinters. In addi- 
tion, disk volumes can be accessed randomly. 


Mass storage volumes can be either file-structured or non- 
file-structured, according to the choice of the user. The I/O 
system services enable programmers to use either the 
physical (device-assigned) address or a logical (driver-as- 
signed) address for directly addressing blocks on foreign 
mass storage volumes. A foreign volume can be either 
non-file-structured or structured with the user’s own file 
structure. If the volume is structured using the operating 
system’s Files-11 disk file or ANS! magnetic-tape struc- 
ture, the I/O system services enable the programmer to 
address blocks directly using virtual (file system assigned) 
addresses. 


Table 6-1 
System Services 


I/O SERVICES FOR DEVICE DEPENDENT I/O 


Assign I/O Channel (SASSIGN) 


Deassign I/O Channel 
(SDASSGN) 


Mount Volume (SMOUNT) 


Dismount Volume ($DISMOU) 


Get Device/Volume Information 
(S$GETDVI) 


Allocate Device (SALLOC) 


Deallocate Device (SDALLOC) 
Queue I/O Request ($QIO) 


Queue I/O Request and wait 
(SOIOW, $INPUT, $OUTPUT) 


Cancel I/O Requests 
(SCANCEL) 


Formatted ASCII Output 
($FAO, $FAOL) 


Establish a path for an I/O request. 
Establish a path for network operations. 


Release a path for an I/O request. 
Release a path from the network. 


Allow a process to mount a single volume or 
volume set. 


Allows a process to dismount a volume set. 


Return information about an I/O device. 


Reserve a device for exclusive use bya 
process and its subprocesses. 


Relinquish exclusive use of a device. 


Initiate an input or output operation and con- 
tinue processing while I/O is in progress. 


Initiate an input or output operation and 
cause the process to wait until the I/O is 
complete before continuing execution. 


Cancel pending I/O requests on a channel. 


Perform ASCII string substitution and con- 
vert numeric data to ASCII representation 
and substitute in output. 


1/0 SERVICES FOR MAILBOXES AND MESSAGES 


Create Mailbox and Assign 
Channel (SCREMBX) 


Delete Mailbox (SDELMBX) 
Broadcast (S6BRDCST) 


Send Message Accounting 
Manager ($SNDACC) 


Send Message to Symbiont 
Manager (S$SNDSMB) 


Send Message to Operator 
(SSNDOPR) 


Creates a temporary. 
Creates a permanent mailbox. 


Mark a permanent mailbox for deletion. 


Send a high-priority message to an specified 
terminals or terminal. 


Control accounting log file activity. 
Write an arbitrary message to the account- 
ing log file. 


Request symbiont manager to initialize, 
modify or delete a printer, device, or batch 
job queue. 

Request symbiont manager to queue a batch 
or print file, or delete or change characteris- 
tics of a queued file. 


Write a message to a designated operator(s) 
terminal(s). 

Enable or disable an operator’s terminal, 
send a reply to a user request or initialize the 
operator's log file. 
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Send Message to Error Logger Write arbitrary data to the system error log 
(SSNDERR) file. 
Get Message ($GETERR) Return text of system or application error 


message from message file. 


Put Message($PUTMSG) Write a system or application error message 
to the current output and error devices. 


LOGICAL NAME SERVICES 


Create Logical Name Place logical 

(SCRELOG) name/equivalence name pair in process 
logical name table. 
Place logical 


name/equivalence name pair in group logi- 
cal name table. 

Place logical 

name/equivalence name pair in system logi- 
cal name table. 


Delete Logical Name Remove logical 

($DELLOG) name/equivalence name pair in process 
logical name table. 
Remove logical 
name/equivalence name pair in group logi- 
cal name table. 
Remove logical 
name/equivalence name pair in system logi- 
cal name table. 


Translate Logical Name Search logical name table for a specified 
(STRNLOG) logical name and return its equivalence 
name when the first match is found. 


EVENT-FLAG PROCESSING 


Associate Common Event-Flag Create a temporary common event-flag 
Cluster (SASCEFC) cluster. 
Create a permanent common event flag 
cluster. 


Create acommon event flag cluster in mem- 
ory shared by multiple processors. 
Establish an association with an existing 
common event flag cluster. 


Disassociate Common Event- Cancel association with a common event flag 
Flag Cluster (SDACEFC) cluster. 
Delete Common Event Flag Mark a permanent common event flag clus- 
Cluster (SDLCEFC) ter for deletion. 
Set Event Flag (SSETEF) Turn on an event flag in a process local event 
flag cluster. 
Turn on an event flag ina common event flag 
cluster. 
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Clear Event Flag (SCLREF) 


Read Event Flags (SREADEF) 


Wait for Single Event Flag 
(SWAITFR) 


Wait for Logical OR of Event 
Flags (SWFLOR) 


Wait for Logical AND of 
Event Flags (SWFLAND) 


Turn off an event flag in a process-local 
event flag cluster. 

Turn off an event flag in a common event flag 
cluster. 


Return the status of all event flags in a proc- 
ess-local event flag cluster. 

Return the status of all event flags in a com- 
mon event flag cluster. 


Place the current process in wait state pend- 
ing the setting of an event flag in a process- 
local event flag cluster. 

Place the current process in wait state pend- 
ing the setting of an event flag ina common 
event flag cluster. 


Place the current process in wait state 
pending the setting of any one of a specified 
set of flags in a process-local event flag clus- 
ter. 

Place the current process in wait state pend- 
ing the setting of any one of a specified set of 
flags ina common event flag cluster. 


Place the current process in wait state pend- 
ing the setting of all specified flags in a proc- 
ess-local event flag cluster. 

Place the current process in wait state 
pending the setting of all specified flags ina 
common event flag cluster. 


LOCK MANAGEMENT SERVICES 


Queue Lock Request ($ENO) 


Queue Lock Request and wait 
for Event Flag (SENOW) 


Dequeue Lock Request ($DEQ) 


Allows users to queue requests to access a 
resource or to convert lock request mode to 
another lock request mode. 


Combines the queue lock request and the 
wait for single event-flag (SWAITFR) system 
services. 


Unlocks resource that the calling process 
previously locked using the Queue Lock Re- 
quest (S$ENQ) system service. 


AST (ASYNCHRONOUS SYSTEM TRAP) PROCESSING 


Set Power Recovery AST 
(SSETPRA) 


Set AST Enable (SSETAST) 
Declare AST (S$DCLAST) 
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Establish AST routine to receive control fol- 
lowing power recovery conditions. 


Enable or disable the delivery of ASTs. 


Queue an AST for delivery. 
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CONDITION HANDLING SERVICES 


Set Exception Vector Define condition handler to receive control in 

(SSETEXV) case or hardware- or software-detected ex- 
ception conditions. 

Set System Service Failure Request or disable generation of a software 

Exception Mode ($SETSFM) exception condition when a system service 
call returns an error or severe error. 

Unwind from Condition Delete a specified number of call frames 

Handler Frame (SUNWIND) from the call stack following a nonrecovera- 
ble exception condition. 

Declare Change Mode or Designate a routine to receive control when 

Compatibility Mode Handler change mode to user instructions are en- 

(SDCLCHM) countered. 


Designate a routine to receive control when 
change mode to supervisor instructions are 
encountered. 

Designate a routine to receive control when 
compatibility mode exceptions occur. 


PROCESS CONTROL SERVICES 


Create Process (S6CREPRC) Create a subprocess. 
Create a detached process. 
Set Process Name ($SETPRN) Establish a text string to be used to identify 
the current process. 
Get Job/Process Information Return information about the current proc- 
(SGETJPI) ess. 


Return informaton about the current process 
context of other processes in the same 
group. 

Return information about any other process 
in the system. 


Delete Process (6DELPRC) Delete current process or subprocess. 
Delete another process in the same group. 
Delete any process in the system. 


Hibernate (SHIBER) Make the current process dormant but able 
to receive ASTs until a subsequent wakeup 
request. 

Schedule Wakeup (S$SCHDWk) Wake a process after a specified time inter- 
val or ata specific time. 

Cancel Wakeup (SCANWAKk) Cancel a scheduled wakeup request. 

Wake (SWAKE) Restore executability of the current process 


or hibernating subprocess. 

Restore executability of a hibernating proc- 
ess in the same group. 

Restore executability of any hibernating 
process in the system. 
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Suspend Process (S$SUSPND) 


Resume Process (SRESUME) 


Exit ($EXIT) 


Force Exit ($FORCEX) 


Declare Exit Handler 
(S$DCLEXH) 


Cancel Exit Handler 
(SCANEXH) 


Set Priority (6SETPRT) 


Set Resource Wait Mode 
(SSETRWM) 


Set Privileges (SSETPRV) 
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Make the current process or subprocess no- 
nexecutable and unable to receive ASTs un- 
tila subsequent resume or delete request. 
Make another process in the same group 
nonexecutable and unable to receive ASTs 
until a subsequent resume or delete request. 
Make any process in the system nonexecu- 
table and noninterruptable until a subse- 
quent resume or delete request. 


Restore executability of a suspended sub- 
process. 

Restore executability of a suspended proc- 
ess in the same group. 

Restore executability of any suspended 
process in the system. 


Terminate execution of an image and return 
to the command interpreter. 


Cause image exit for the current process or 
subprocess. 

Cause image exit for a process in the same 
group. 

Cause image exit for any process in the sys- 
tem. 


Designate a routine to receive control when 
an image exits. 


Cancel a previously established exit han- 
dling routine. 


Change the execution priority for the current 
process or a subprocess. 

Change the execution priority for a process 
in the same group. 

Change the execution priority for any proc- 
ess in the system. 


Request wait, or that control be executed be- 
Cause a system resource is not available. 


Allow a process to enable or disable 
specifed user privileges. 


TIMER AND TIME CONVERSION SERVICES 


Get Time ($GETTIM) 


Convert Binary Time to 
Numeric (6NUMTIM) 


Convert Binary Time to ASCII 
(SASCIIM) 


Convert ASCII String to 
Binary Time (S$BINTIM) 


Return the date and time in system format. 


Convert a date and time from system format 
to numeric integer values. 


Convert date and time from system format 
time to an ASCII string. 


Convert date and time in an ASCII string to 
system date and time format. 
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Set Timer (SSETIMR) 


Cancel Timer Request 
(SCANTIM) 


Schedule Wakeup (SSCHDWk) 


Cancel Wakeup (SCANWAK) 


Set System Time (SSETIMB) 
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Request setting of an event flag or queueing 
an AST, based on an absolute or delta time 
value. 


Cancel previously issued timer requests. 


Schedule a wakeup for the current process 
or hibernating subprocess. 

Schedule a wakeup for a hibernating proc- 
ess in the same group. 

Schedule a wakeup for any hibernating 
process in the system. 


Cancel a scheduled wakeup request for the 
Current process or a hibernating subpro- 
cess. 

Cancel a scheduled wakeup request for a 
hibernating process in the same group. 
Cancel a scheduled wakeup request any hi- 
bernating process in the system. 


Set or recalibrate the current system time. 


MEMORY MANAGEMENT SERVICES 


Adjust working Set Limit 
(SADJWSL) 


Expand Program/Control 
Region (SEXPREG) 


Contract Program/Control 
Region (SCNTREG) 


Create Virtual Address Space 
(SCRETVA) 


Delete Virtual address Space 
(SDELTVA) 


Create and Map Section 
(SCRMPSC) 


Change the maximum number of pages that 
a process can have in its working set. 


Add pages at the end of the program or con- 
trol region. 


Decrease pages from the end of the pro- 
gram or control region. 


Add pages to the virtual address space 
available to an image. 


Make arange of virtual addresses unavail- 
able to an image. 


Identify a disk file as a private section and 
establish correspondence between virutal 
blocks in the file and the processes’ virtual 
address space. 

Identify a disk file containing sharable code 
or data as a temporary global section and 
establish correspondence between virtual 
blocks in the file and the processes’ virtual 
address space. 

Identify a disk file containing sharable code 
as a permanent global section and establish 
correspondence between virtual blocks in 
file and the processes’ virtual address 
space. 


Update Section file on Disk 
(SUPDSEC) 


Map Global Section 
(SMGBLSC) 


Delete Global Section 
(SDGBLSC) 


Set Protection on Pages 
(SSETPRT) 


Lock Pages in working Set 
(SLKWSET) 


Unlock Pages in Working Set 
(SULWSEP) 

Purge Working Set (SPURGWS) 
Lock Page in Memory ($LCKPAG) 


Unlock Page in Memory (SULKPAG) 


Set Process Swap Mode 
(SSETSWM) 
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Identify a disk file containing sharable code 
as a system global section and establish cor- 
respondence between virtual blocks in a file 
and the processes’ virtual address space. 
Identify one or more page frames in physical 
memory as a provate or global section and 
establish correspondence between virtual 
blocks in a file and the processes’ virtual ad- 
dress 


Write modified pages or a private or global 
section into the section file. 


Establish a correspondence between a glo- 
bal section and a processes’ virtual address 
space. 


Mark a permanent global section for dele- 
tion. 
Mark a system global section for deletion. 


Control access to a range of virtual ad- 
dresseds. 


Specify that particular page cannot be 
paged out of the process’ working set. 


Allow previously locked pages to be out of 
the working set. 


Remove all pages within a specified range 
from the current working set. 


Specify that particular pages may not be 
swapped out of memory. 


Allow previously locked pages to be 
swapped out of memory. 


Control whether or not the current process 
can be swapped out of the balance set. 


GENERAL PROCESS STATE CONTROL 


Set Resource Wait Mode 
(SSETRWM) 


Set Process Swap Mode 
(SSETSWM) 


Establish whether or not control should be 
returned immediately when a system service 
can not be executed because a resource Is 
not available. 


Prevent this process from being (or allow to 
be) swapped out of the balance set. 
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CHANGE MODE SERVICES 
Change Mode to Executive 
(SCMEXEC) 


Change Mode to Kernel 
(SCMRRNL) 


Adjust Outer Mode Stack 
Pointer (ADJSTK) 


A special type of record-oriented device is the mailbox, 
which is a virtual device that a process creates for the re- 
ceipt of messages from other processes. Mailboxes are 
treated like any other record-oriented device: they can be 
read from and written to using either the I/O system ser- 
vices or record management services. Mailboxes are dis- 
cussed further in the section, Interprocess Communica- 
tion. 


Before a process requests I/O to a device, it obtains a 
channel assignment from the operating system. A process 
can use a device name or a /ogical name in a channel as- 
signment request to identify the device for which the chan- 
nel is desired. 


A device name is a unique name assigned by the operating 
system to a particular physical device. The name identifies 


the type of device and its controller and line or unit num-. 


ber, as applicable. For example, DMA3: is the operating 
system's device name for the RKO6 disk drive unit three on 
controller A, and TTA12: is the operating system’s name 
for the terminal on line 12 on multiplexer A. 


A logical device name is any string of characters a user or 
program assigns to a device name assigned by the operat- 
ing system. The Create-Logical-Name system service not 
only enables a process to define logical names for device 
names, but it enables a process to assign logical names to 
any portion of a file specification or to other logical names. 
Furthermore, logical names can be assigned on a per- 
process, per-group, or systemwide basis. (For more infor- 
mation on logical names, refer to the Information Manage- 
ment Facilities section.) 


Once a channel is obtained, a process can issue I/O re- 
quests on that channel. The Queue-l/O-Request system 
service is a general |/O-request interface. All 1/O using 
system services is asynchronous: both I/O and computa- 
tion can take place simultaneously. An 1/O request is sim- 
ply queued to the device driver, and control is normally re- 
turned to the requesting process before the I/O operation 
is complete. 


The process is responsible for synchronizing with I/O 
completion. The process can simulate synchronous |/O 
processing by using the Queue I/O Request and Wait sys- 
tem service, or it can continue to execute during the I/O 
operation and request I/O completion notification using 
the general purpose event-flag or asynchronous system- 
trap notification mechanisms. 


Execute a given routine in executive mode. 


Execute a given routine in kernel mode. 


Modify the current stack pointer for a less 
privileged access mode. 


Realtime interface extensions (connect-to-interrupt facility 
and map-to-Il/O page) provide the realtime programmer 
(MACRO and BLISS-32) a technique of more simply inter- 
facing to user-specialized devices. The connect-to-inter- 
rupt facility can be used to cause an interrupt to be deliv- 
ered directly to the user’s program. As a consequence of 
this approach, response to the interrupt occurs in the 
shortest time possible, without writing an I/O driver. 


The map-to-I/O page is a complement to the connect-to- 
interrupt facility because it allows the user program to ac- 
cess the device registers. Before these extensions were 
made available, the user had to write both a device driver 
and an application program, to achieve the same results. 


Local Event Flags 

An event flag is a status bit used for posting an event such 
as I/O completion or elapsed time interval. Event flags are 
an extremely efficient means of starting up or synchroniz- 
ing procedures. 


Each process has available for its own use two local event- 
flag clusters, each of which contains 32 event flags. Eight 
flags in the first cluster are reserved by the operating sys- 
tem. A process can set, clear, and read individual event 
flags, as well as wait for one or more event flag to be set. 
The advantage to having two clusters of event flags is that 
the flags in each cluster can be treated as a related group. 
A process can wait until any of a specified set of flags in a 
particular cluster is set or can wait until all of a specified 
set of flags in a particular cluster are set. 


Aside from their use with I/O processing and timer sche- 
duling, a process can assign its own meanings to local 
event flags. Event flags can be used to coordinate several 
asynchronous events, such as multiple |/O-request com- 
pletions, or to simplify asynchronous processing. For ex- 
ample, a program may wish to know if a terminal user has 
typed a CTRL/C (indicating the desire to interrupt execu- 
tion) only at well-defined points during processing. An 
asynchronous system-trap routine can set an event flag to 
indicate that a CTRL/C has been received. 


Lock-Management Services 

Lock-management services provide a mechanism for syn- 
chronizing access to common resources by cooperating 
processes. There are six choices of lock mode, each with a 
different level of sharing. Resources are defined by a tree- 
structured nametable. The depth of the hierarchy em- 
ployed in the nametable determines the degree of granu- 
larity in controlling access to the resource. 


Asynchronous System Traps 

An asynchronous system trap (AST) is a software-simu- 
lated interrupt used for event notification within a process. 
An asynchronous system-trap routine is a procedure that 
handles an AST. AST routines provide an efficient means 
for processing events that can occur at any time during 
processing (such as terminal input) because they elimi- 
nate the need for polling. 


For example, a program can specify AST routines for I/O- 
request processing, timer scheduling, and power recov- 
ery. When the I/O operation completes, time interval ex- 
pires, or power is restored, the operating system declares 
an AST. When the AST is delivered, the operating system 
interrupts the process and executes the AST routine. A 
process can be hibernating and still receive ASTs de- 
clared for it. 


Code executing at one processor access mode can de- 
clare an AST for code executing at the same or a less-pri- 
vileged access mode. The operating system automatically 
disables AST delivery while an AST routine is executing, 
and code executing at a given access mode can explicitly 
disable AST delivery. While ASTs are disabled, the 
operating system queues any ASTs waiting to be delivered 
to that access mode in the order in which they were de- 
clared. When AST delivery is again enabled for that access 
mode, the ASTs are delivered in the order in which they 
were queued. 


Exception Conditions and Condition Handlers 

A program may request the processor or a system service 
to do operations they cannot perform correctly. For exam- 
ple, a program might inadvertently issue a divide instruc- 
tion using a divisor of zero. Normally there is no way to 
recover, and the program cannot continue. In this system, 
however, it is possible for a program to continue if it de- 
clares a condition handler that can correct the situation. If 
a user program declares a condition handler, control 
transfers to the condition handler when an exception con- 
dition occurs. 


This system treats all errors (or special events that occur 

synchronously with respect to a program’s execution) as 

exception conditions and provides a general purpose me- 

chanism for dispatching condition handlers. Exception 

conditions include: 

® Errors from which the processor cannot normally re- 
cover, such as the divide-by-zero arithmetic trap. 


® Special conditions for which a program does not wish to 
test continually; for example, the floating-point-overflow 
arithmetic trap or unsuccessful system-service comple- 
tion. 


Some of the exceptions detected by the processor are 
handled automatically by the operating system. For exam- 
ple, the pager is a condition handler for translation-buffer- 
not-valid faults. 


In addition to processor and system-service-detected ex- 
ception conditions, any software procedure can define 
cases for which it will fail or produce an exception, by call- 
ing a system library procedure that signals an exception 
condition. The search sequence for a condition handler is 
independent of the nature of the exception condition; the 


search sequence is the same whether an exception condi- 
tion is detected by hardware or software. 


A process can declare two kinds of condition handlers: 
those that are process-wide and those that are applicable 
to individual procedures. Process-wide condition handlers 
are declared using the Set Exception Vector system ser- 
vice, which enables a process to declare a primary and a 
secondary condition handler. Condition handlers applica- 
ble to individual procedures are declared by the pro- 
cedure when it is called using one instruction. 


When an exception condition occurs, the exception 
dispatcher does not differentiate between exception con- 
ditions; it simply transfers control to the first condition 
handler it can find that wants to handle the exception con- 
dition. This method for handling exception conditions is an 
efficient means of transferring control to the appropriate 
condition handler rapidly, since condition handling is de- 
fined by the module or modules in which an exception 
condition may occur. 


For programs written in high-level languages, each lan- 
guage can have different definitions of what is and what is 
not an exception condition. As the user program calls lan- 
guage functions, the exception conditions for those func- 
tions can be handled locally with the procedure. And when 
exception conditions should be handled on a process- 
wide basis, the primary and secondary exception vectors 
provide a top-level exception condition trap. For example, 
when a user program is linked with the debugger, the de- 
bugger uses the primary exception vector to declare a 
process-wide condition handler. 


INTERPROCESS COMMUNICATION AND CONTROL 
This system supports both simple and complex job defi- 
nitions. A simple job is a detached process that is either 
created by the operating system on behalf of the user who 
logs in at a terminal or created for the purpose of execut- 
ing a batch job. A simple job serially executes images, but 
it does not create subprocesses. 


A complex job is one in which a detached process creates 
subprocesses in which designated images execute. These 
subprocesses can also create their own subprocesses, 
and so on. The advantage of a complex job over a simple 
job is that a complex job performs parallel processing op- 
erations because it has control over several images exe- 
cuting concurrently. 


The following sections describe the services that enable a 
process to control and communicate with other processes. 


Process Control Services 

The system services provide process control by enabling a 

process to: 

® Create and delete subprocesses. 

© Hibernate, then reactivate a process via the Hiber- 
nate/Wake and Suspend/Resume system services. 


The ability to create subprocesses is granted to a user by 
the system manager when the number of subprocesses a 
job can create is a resource limit. When a process creates 
a subprocess, it can give the subprocess all or some of its 
privileges, and its resource quotas and limits are shared 
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with the subprocess. Other resource quotas are shared 
between the creator and the subprocess. 


The Hibernate/Wake and Suspend/Resume mechanisms 
are methods of process control that are especially efficient 
in realtime applications. They allow the user to prepare an 
image for execution and then place it into a wait state until 
some event occurs that requires its activation. 


The Hibernate system service provides the greatest flexi- 
bility in sequencing processes for execution. When a Hi- 
bernate system service is invoked, normal execution can 
be resumed only by issuance of a $WAKE system service 
(or a variant, $SCHDWK, which allows wakeup at an abso- 
lute time or at a fixed time interval). However, a hibernating 
process can be interrupted temporarily by the delivery of 
an AST (Asynchronous System Trap). When the AST 
service routine completes execution, the process contin- 
ues hibernation. If, however, the process calls the $WAKE 
system service during execution of the AST service rou- 
tine, the process wakes itself after the service routine com- 
pletes. 


Using the $SUSPEND system service, a process can place 
itself or another process into a wait state similar to 
hibernation. However, a suspended process cannot be as 
easily activated as a hibernating one. It cannot, for exam- 
ple, be interrupted by delivery of an AST. Nor can it wake 
itself, but can only resume normal execution following is- 
suance of a$RESUME system service by another process. 


The interprocess system services can be used by a proc- 
ess to control another process executing in the same 
group. While only an owner process can create and delete 
subprocesses, a process can be given the privilege to sus- 
pend, resume, and wake other processes in its group. 


Jobs with sufficient privilege can also create detached 
processes and delete, suspend, resume, or wake any 
process in the system. These privileges are normally re- 
served for the operating system or the system manager. 


Interprocess Communication Facilities 

In addition to providing process control services, the oper- 
ating system provides process communication facilities for 
synchronizing execution, for sending messages, and for 
sharing common data. The techniques that cooperating 
processes can use to communicate are: 

© Common event flags 

® Mailboxes 

® Lock management services 

® Shared areas of memory 

® Shared files (RMS) 


Common event flags are available by group association to 
processes within jobs. Mailboxes and shared areas of 
memory are more general purpose facilities that can be 
limited or unlimited in scope. They can be limited to a spe- 
cific member family within a group or to a specific group of 
jobs or to all jobs in the system. 


Common Event Flags 

In addition to the local event flags available to each proc- 
ess, cooperating processes can communicate using com- 
mon event flags. Every group in the system can define any 
number of common event-flag clusters. Each cluster 


contains 32 flags. The flags can be assigned any meaning 
for the processes in the group. 


Each process in a group can associate with up to two of its 
group’s common event-flag clusters at one time. A proc- 
ess can read, set, clear, or wait for common event flags to 
be set. The ability to read, set, or clear event flags is con- 
trolled by the protection code and User Identification Code 
assigned to the common event-flag cluster. 


Common event-flag clusters can also be used by cooper- 
ating processes on different processors in a multiport 
memory configuration. 


Lock-Management Services 

The lock-management services, like the common event 
flag services, provide a tool for synchronizing process ac- 
tion. While common event flags can be used only by a 
process within the same group, the lock-management ser- 
vices can operate on a systemwide basis. In fact, VAX-11 
RMS uses this service to regulate file sharing. 


These services allow users to develop complex resource- 
sharing applications — for example, database systems. It 
provides a resource nametable for defining a resource, a 
variety of lock modes for controlling access to it, and the 
means for processes to queue lock requests. 


The lock-management service does not directly control 
access to resources; rather, it provides a mechanism for 
assigning resource names that are stored in a common 
namespace. Processes request access to a resource 
name in a common namespace, and cooperating 
processes understand that when they are granted access 
to a resource name they can then access the resource it- 
self. 


The resource nametable is tree-structured and allows 
users to define their resource to practically any granularity 
or hierarchical depth. 


Concurrency can be increased further by an appropriate 
selection of locking modes. There are six lock modes to 
choose from, each allowing a different sharing scheme 
with other cooperating tasks. The lock modes available 
are: 

® Null lock 

® Concurrent read 

® Concurrent write 

© Protected read 

© Protected write 

® Exclusive 


If a lock request is made on a resource, and if another 
process already has an incompatible lock on that re- 
source, the lock request is still queued until the resource is 
unlocked or the lock has been changed to a compatible 
one. 


A process can have more than one lock at a time. The limit 
on the number of locks depends on the quota assigned to 
the process. That quota is set by the system manager and 
defined in the User Authorization File. 


The lock management services also provide deadlock de- 
tection. A deadlock occurs when a group of locks are wait- 
ing for each other in a circular fashion. If a deadlock situa- 
tion occurs, the lock management service selects one of 


the processes as a “victim,” does not grant that process 
the lock it has been waiting for, and indicates to the 
process that the lock has been denied because the dead- 
lock condition exists. The process can then do whatever 
cleanup is necessary and unlock (or convert its lock on) 
the resource it has — thus breaking the deadlock. 


Mailboxes 

A mailbox is a record-oriented virtual 1/O device created 
by a process. Mailboxes can be used to pass status infor- 
mation or return codes, messages, or any other data from 
one process to another. A process can protect its mail- 
boxes from read and/or write access by any process out- 
side its member family or outside its group. Mailboxes can 
also be used by processes to communicate with other 
processes on different processors in a multiport memory 
configuration. 


All of the I/O system services and record management 
services can be applied to mailboxes. Other processes 
write messages to a processes’ mailbox by queuing write 
requests for the device. A process reads messages in its 
mailbox by queuing read requests for the device. A proc- 
ess can request AST notification when anything is written 
to its mailboxes, and it can assign mailboxes logical 
names. 


Shared Areas of Memory 

The system supports a high degree of code and data shar- 
ing through the use of global sections. A global section is a 
copy of all or a portion of an image or data file that can be 
mapped in a process virtual address space at runtime. 
Global sections can be used for shared-data structures 
and as communication regions for cooperating processes; 
they can also be used simply to eliminate multiple copies 
of image code or data. 


Global sections can be created dynamically by a process 
or they can be permanently present in the system. Dy- 
namically created global sections are mapped into 
processes that reference them, then deleted when no 
more references are made to them. Permanent global sec- 
tions, which are created by a sufficiently privileged proc- 
ess, remain until they are explicitly deleted. They are 
loaded into and removed from memory dynamically, as 
references are made to them. 


Each process that maps a global section into its virtual ad- 
dress space can have a different access privilege to a glo- 
bal section. When a global section is created, it is assigned 
a User Identification Code (UIC) that identifies the group 
and member family to which the global section belongs, 
and a protection code that identifies the read and write ac- 
cess privileges of processes in the system. Global sections 
can be shared by all processes in the system or shared 
only by processes within a particular group or shared only 
by processes within a particular job. One or more control- 
ling process can have write privileges, while other 
processes in the system, group, or job have only read pri- 
vileges. 


A process can map to a global section explicitly by issuing 
a Map-Global-Section system service or can be mapped 
implicitly by referring to a sharable image. If an image 
references a sharable image, the linker does not normally 
include the sharable image in the image. The sharable im- 


age is installed as a global section or set of global sections. 
When the image is executed, the image activator calls the 
Map-Global-Section system service on behalf of the im- 
age. For example, the Common Runtime Procedure Li- 
brary — a sharable image consisting of library procedures 
— is mapped as a systemwide permanent global section. 
The use of permanent global sections significantly reduces 
the size of programs using common library procedures 
and the overall system memory requirements. 


Interprocessor Communication Facility 

VAX/VMS support for the multiport memory subsystem 
means that both user data and subroutines can reside in 
shared memory for access from multiple processors con- 
nected to the multiport memory. All three interprocess 
communication facilities — that is, common event flags, 
mailboxes, and global sections — can reside in multiport 
memory, thus providing interprocessor communication fa- 
cilities. Through the use of logical names, common event 
flags, mailboxes, and global sections can be placed either 
in local or multiport memory, transparently to the pro- 
gram. Common event flags, mailboxes, and global sec- 
tions are the communication facilities permitted in 
multiport memory configurations. 


MEMORY MANAGEMENT 

In a multiprogramming system, many processes coexist 
simultaneously in main memory. The system switches 
between these processes, giving each some time to exe- 
cute. In most multiprogramming environments, however, 
the number, size, and kinds of concurrently executing 
processes change rapidly, while the amount of memory 
available for processes remains constant. Users log on 
and off the system, production activities vary periodically, 
and special production jobs occur. Since it is generally 
inefficient to have available the maximum amount of mem- 
ory that might ever be needed at one time, it becomes the 
task of the operating system to provide a dynamic memory 
that responds to the changing multiprogramming environ- 
ment. 


VAX/VMS uses two interdependent complementary tech- 
niques to allocate limited memory to competing 
processes: paging and swapping. These techniques re- 
lieve the general programmer of concern for memory allo- 
cation, yet still allowing system programmers to optimize 
program performance in limited configurations. This sec- 
tion and the following section on scheduling discuss how 
this system’s paging and swapping techniques extend 
limited memory resources with minimum effect on the sys- 
tem or programs when the system has sufficient memory 
to hold all concurrently executing processes. 


Mapping Processes into Memory 

The operating system’s memory management software is 
responsible for creating and maintaining the information 
used to map the virtual addresses used in a program to 
physical memory addresses. The unit mapped is the page, 
which is a block of 512 contiguous byte locations in physi- 
cal memory. 

Virtual addresses are also grouped into 512-byte pages, 


and each page of virtual addresses can be mapped to a 
page of real memory locations. Any number of virtual 


pages can be mapped to one physical page. Unlike sys- 
tems that partition or statically allocate portions of physical 
memory, this system dynamically allocates physical mem- 
ory, with the result that pages of a process can be scat- 
tered anywhere throughout memory. It is never the 
concern of the programmer to determine how physical 
memory is allocated. To illustrate this, Figure 6-4 shows 
how two processes might be mapped into physical mem- 
ory. 


When a process is created, the operating system sets up 
its mapping information, called page tables. Each process 
has its own page tables mapped by system-region virtual 
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addresses. (Refer to the Processor section on memory 
management for a complete description.) Initially, a proc- 
ess page table simply maps those pages of the control re- 
gion that define the permanent-process context. 


When a program is linked, the addresses the linker as- 
signs in the image are always virtual addresses. The linker 
has no knowledge of how physical memory is allocated. Its 
primary function is to build descriptions of the size and 
protection requirements of the program’s code and data 
areas. 


When an image is executed, the memory management 
software uses the linker’s descriptions of code and data 
areas to map image virtual pages to physical pages. The 
operating system’s image activator builds the image’s 
mapping information in the process’ page tables. 


Process Virtual Memory and Working Set 

The total virtual memory requirement of a process is called 
process virtual memory. Process virtual memory consists 
of all pages of the process program region and control re- 
gion that are mapped by the process page tables. 


At any one time, some of the pages of process virtual 
memory can be mapped to disk and some to physical 
memory. The physical memory requirement of a process 
is the process working set. When a process is executing, a 
process working set consists of all the pages of a process’ 
virtual memory residing in physical memory that the proc- 
ess can directly access without incurring a page fault, p/us 
any actively used portions of the process page tables and 
process header information. 


The working set is a dynamic characteristic of a process 
that has both minimum and maximum size limits. The sys- 
tem designates a required minimum number of pages that 
has to be in a process working set, and the system man- 
ager defines the maximum number of pages allowed in 
any one job’s working set in the user authorization file. The 
size of a process working set affects its paging and swap- 
ping performance, as well as the number of process work- 
ing sets that can be resident when the process working set 
is resident. 


A process can increase or decrease its working set, within 
the authorized limits, through the use of command-lan- 
guage commands or system-service calls. 


Under VAX/VMS, working-set size adjustments are made 
automatically by the operating system. This facility, when 
enabled by the system manager, monitors the page fault 
rate of a process and automatically increases or 
decreases the working set (again within authorized limits) 
to optimize performance and memory usage. This au- 
tomatic adjustment provides a more immediate response 
in system reaction/performance. 


Paging 

Through its paging technique, the operating system can 
execute programs that are too large to fit in the amount of 
physical memory allocated to a process, without requiring 
the programmer to define overlays. Inactive portions of a 
program are automatically stored ondisk while the active 
portions are resident in memory. When the program refer- 
ences a disk-resident portion of the program, the operat- 
ing system reads in, or pages in, the referenced portion, 


moving out other portions of the program to disk if neces- 

sary. This system’s paging technique has several features 

that distinguish it from other techniques: 

e Clustering, or the ability to read in several pages at one 
time. 


e Paging processes against themselves, not against the 
entire system. 


e Maintaining an available-page pool from which proc- 
esses can recover recently discarded pages without in- 
curring disk I/O. 

e Writing back to disk only the modified pages that are re- 
leased from a process working set and only writing them 
when several have accumulated. 

e Activating a process waiting for page fault I/O to execute 
AST routines when they are delivered. 


When the operating system activates an image for the first 
time, a number of pages are read into memory from the 
image file ondisk. The number of pages read in the first 
time can be controlled by a cluster factor the programmer 
can assign optionally per image. The ability to read in sev- 


eral pages at once allows the image to execute for some 
time without incurring page faults and provides signifi- 
cantly improved responsiveness in starting programs. 


A process is subsequently paged only when it executes an 
image that needs more pages than the process is allowed 
to have in its working set. If the number of pages in the im- 
age plus the number of pages for the remainder of the 
process is less than the working-set size limit, all the pages 
are read in, and the process is never paged. 


If all the pages are not read in initially, at some point the 
image will reference the pages that have not been read in. 
At that time, the process incurs a page fault, that is, a 
reference to a page not mapped in the process working 
set. 


The operating system’s pager is a condition handler that 
executes when a process incurs a page fault. If the work- 
ing-set size limit has not yet been reached, the pager 
reads in the faulted page from disk plus any additional 
pages — again, according to a cluster factor for that sec- 
tion of the image. 
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If a page fault occurs when the working-set size limit is 
reached, the pager obtains a page from a pool of available 
pages to read in the faulted page, releases the least re- 
cently faulted page from the process working set into the 
pool, and writes it to disk if it has been modified. Figure 6-5 
illustrates two different-sized working sets for a process 
running the same program in each case. The illustration 
shows the order in which the pages were faulted. (Refer to 
Figure 6-2 to see how the pages appear in virtual address 
space.) 


The pager pages a process only against itself. It does not 
release pages of one process to satisfy another’s needs. 
This ensures that only those processes that need paging 
are affected by paging. Other processes in the system 
need not be affected by another process’s memory re- 
quirements. 


The list of available pages works as a cache of pages that 
effectively extends a working-set size above its limit when 
few processes are competing for memory resources and 
there are many pages in the list. If a process faults a page 
that was released and is still in the list, the page does not 
have to be read in from disk; it is simply taken from the list 
and remapped into the working set. 


When a page is released, it is placed on one of two lists: 
the free-page list or the modified-page list. Modified pages 
are pages the process has written into and, if they need to 
be added to the free-page list to be used by another proc- 
ess, must be saved on disk. Modified pages are only writ- 
ten to disk when the modified-page list exceeds a 
threshold size or when an image’s execution is terminated 
and the files containing the modified pages must be 
closed. When modified pages are written, they are writen 
in clusters, to increase system performance. 


Virtual Memory Programming 

The processor provides the programmer with a large 
virtual address space and rapid address translation, and 
the operating system provides the programmer with ex- 
tremely efficient mapping and paging algorithms. Further- 
more, these memory management mechanisms are totally 
transparent to the application programmer. It is not neces- 
sary for a programmer to be concerned with address 
allocation or page mapping: the high-level language com- 
pilers and the linker take advantage of the memory man- 
agement mechanisms to set up the memory allocation op- 
timally for most programming requirements. 


For those systems with limited memory or special 
processing requirements, however, this system enables 
users to control and optimize memory management. The 
system manager can control the memory allocation re- 
quirements of the system as a whole by initialization par- 
ameters such as desired and minimum acceptable num- 
ber of available pages and can control the memory 
allocation requirements of individual jobs by user au- 
thorization parameters such as paging file usage limit and 
maximum working-set size. It is possible to have a process 
avoid paging entirely by making its working-set size equal 
to its virtual memory requirements, and it is possible to re- 
duce paging by choosing a working set-size that satisfies 
the average demand for pages over time. 
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The programmer also has the ability to control memory al- 
location for images in two ways: through properly coded 
programs and through the memory management system 
services. This system’s memory management software 
optimizes for program locality. Programs that incur paging 
infrequently are those in which the code and data used 
during each stage of processing are contained in the few- 
est possible number of virtually contiguous pages. 


For the most part, the linker allocates virtual addresses so 
that images which require the minimum mapping informa- 
tion possible. The programmer can also ensure that im- 
ages that process large data structures require the least 
possible mapping information and potential paging, by or- 
ganizing data structures as if they were disk-resident files. 
In general, the programmer need not be concerned with 
data structures such as tables and arrays whose elements 
are virtually contiguous and sequentially processed. 


Large data structures that are randomly accessed can, 
however, be optimized. For example, processing down a 
linked chain in which the chain elements are spaced far 
apart with no useful data in between requires an image to 
reference a large number of pages in a short period of 
time. If all of the pages cannot fit in the process working 
set at the same time, the references to successive chain 
elements will incur disk I/O. 


On the other hand, a large data structure can be efficiently 
accessed using directory trees, if a page or set of consecu- 
tive virtual pages contains all one kind of information. One 
page can contain all of the information that points to ran- 
domly arranged, but virtually contiguous, pages that con- 
tain the data processed at that locality. 


VAX/VMS Memory Management Services 

For those who have special processing requirements, 
there are system services that control memory manage- 
ment within the quotas and limits assigned by the system 
manager. These memory management system services 
enable a process to: 

e Modify the working set size limit. 

e Add or delete pages from process virtual memory. 


e Expand or contract the program region or control re- 
gion. 


e Lock pages in the working set. 
e Lock pages in physical memory. 


A program can impose a limit on process working-set size 
anywhere between the minimum required by the system 
and the maximum specified by the system manager. The 
limit can be adjusted in accordance with program beha- 
vior and realtime requirements. By maintaining the smal- 
lest working-set size consistent with an acceptable paging 
rate, a program that temporarily requires a large working 
set can reduce its impact on the system. For example, a 
process control program or simulator might use a small 
working set while processing interactive initialization com- 
mands. Once realtime processing is underway, the pro- 
gram can expand its process working-set size to reduce 
paging. When realtime processing is finished, the program 
can contract the working set. 


A process can dynamically add selected pages to, and de- 
lete selected pages from, its virtual memory. Deleting a 


page is, in effect, saying that the image is no longer going 
to use those virtual addresses, and the operating system 
does not need to map them to pages in virtual memory. 
Deleting read/write pages (such as those used for inter- 
process communication) as soon as they are no longer 
used eliminates the need for the system to write them out 
as modified pages to a paging file. When an image has 
reached its paging-file quota, it can delete pages, in order 
to map other pages in its virtual address space. 


A process can request an extension to the amount of 
virtual memory allocated to its program region. The oper- 
ating system will map zero-filled pages into the process 
virtual address space following the highest addressed 
page allocated for the program region. This service, which 
is useful for dynamically creating data arrays whose size is 
not known beforehand, it eliminates the need for allocating 
a data area in a program image. A process can also extend 
the initial allocation of pages for the user stack by request- 
ing the operating system to map zero-filled pages into 
process virtual address space preceding the lowest-ad- 
dressed page allocated for the control region. VAX/VMS 
automatically extends the user stack if the running pro- 
gram requires more stack space. 


In unusual situations, a process can lock pages in its work- 
ing set. Locking a page in the working set is useful when a 
process does not reference a particular page regularly, 
but the page needs to be in the working set to increase the 
performance of the code in that page. For example, it 
might be desirable to keep the page containing asynchro- 
nous system-trap routines in a working set, to ensure that 
the routines are started up rapidly when an AST is deliv- 
ered. Note, however, that locking a page in the working set 
causes other pages to be paged more frequently, since the 
page will not be paged out, no matter how long it has been 
in the working set. A page can be unlocked when it is no 
longer necessary to keep it in the working set. 


It is also possible to lock pages in memory. A page locked 
in memory is not only locked in the working set, but is, 
moveover, not swapped out with the process. This service 
is useful for realtime processes that need to keep buffers 
in memory for I/O transfers. 


PROCESS SCHEDULING 

VAX/VMS features event-driven scheduling based on 
process priority. Unlike traditional timeshared scheduling 
systems, this system’s ability to respond to events enables 
it to dispatch realtime processes efficiently as well as 
share processing time among normal processes compet- 
ing for resources. Furthermore, priority assignment en- 
ables the user to bias processor time allocation based on 
process activity, to bias the allocation absolutely for cer- 
tain processes, or to mix both allocation methods. 


The operating system’s scheduler and swapper are 
responsible for ensuring that the processes executing in 
the system receive processor time commensurate with 
their priority, which is controlled by assignment, and with 
their ability to execute, which is controlled by system 
events. 


System Events and Process States 
In VAX/VMS, dispatching a process for execution involves 
little decision making. The selected process is always the 
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highest-priority executable process. The real scheduling 
decisions are made as the result of system events that 
make processes executable. 


A system event is an event that affects the ability of a proc- 
ess in the system to execute. System events include events 
external to the process currently executing, such as I/O 
completion or timer interrupt. System events also include 
events internal to the process currently executing. The 
process can issue a wait request or a hibernate request, or 
it can request or release a system resource — for example, 
a page of memory. 


Every active process in the system is listed in one of sev- 
eral state queues that identifies whether or not a process is 
executable, and if not, the event or resource for which the 
process is waiting. Whenever a system event occurs, the 
scheduler adjusts the process state queues accordingly. 
For example, the scheduler adds a process to the executa- 
ble state queue when a resource for which it is waiting be- 
comes available or removes it when it requests an event or 
resource for which it must wait. 


The executable state queue supplies the scheduler with a 
list of processes that are eligible to execute. Priority deter- 
mines which process among those eligible can execute. 
Rescheduling occurs when a system event makes execu- 
table a process with higher priority than the one currently 
executing. 


Unlike timeshared scheduling, therefore, event-driven 
scheduling is based on the activities of the processes 
themselves, not on a time limit imposed by the scheduler. 
Because scheduling intervals are determined by system 
events, the interval between rescheduling is random. 
Quantum keeping and requested timer events provide a 
minimum level of event activity but, in practice, the aver- 
age interval between events is determined by the duration 
of the typical 1/O operation. 


Priority: Realtime and Normal Processes 

The scheduler recognizes 32 scheduling priorities; priority 
31 is high and 0 is low. Priorities 31-16 are for realtime 
processes, and priorities 15-0 are for normal processes. 
When a process is created, the system assigns it a sche- 
duling priority. A program image that the process exe- 
cutes can modify the process priority using a system ser- 
vice. The system manager grants jobs the privilege to 
execute at realtime priorities. 


The scheduler maintains a queue for each scheduling pri- 
ority. Processes having the same priority are listed in the 
same queue. The priority assigned to a process when it is 
created is its base priority. The scheduler does not alter 
the priority of a realtime process during execution. The 
scheduler may temporarily increase the priority of a nor- 
mal process during its execution, but its priority never 
drops below its base priority. 


Scheduling by strict priority for realtime processes — and 
by potentially modifying priority for normal processes — 
allows the scheduler to achieve maximum overlap of com- 
pute and 1|/O activities while still remaining responsive to 
high-priority realtime applications. 


Scheduling Realtime Processes 
When a system event occurs that makes a realtime proc- 


ess eligible to execute, it receives control of the processor, 
unless another higher priority process is currently execut- 
ing. A realtime process retains control of the processor 
until it finishes execution, enters a wait state, or is 
preempted by a higher-priority process. (Note that under 
VAX/VMS, realtime processes actually have a higher pri- 
ority than system processes; this ensures ensuring that 
realtime processing will never be encumbered by system 
overhead.) 


A higher priority realtime process can preempt any lower- 
priority process whenever a system event occurs that 
makes it eligible to execute. For example, a device inter- 
rupt can occur that signals the completion of an I/O trans- 
fer requested by the higher priority realtime process. 


When a realtime process is preempted to dispatch a proc- 
ess of higher priority, the preempted process is placed at 
the end of its priority queue. This rotates processes within 
a priority, with the result that available processor time is 
distributed among processes of the same priority. 


Scheduling Normal Processes 

When no realtime processes are executing, the scheduler 
distributes processor time among the processes on the 
normal priority levels. As with realtime processes, the 
scheduler selects the highest-priority ready-to-execute 
normal process. That process then executes until it fin- 
ishes execution, enters a wait state, or is preempted by a 
higher-priority process. Unlike realtime process schedul- 
ing, however, the scheduler modifies normal process pri- 
ority whenever a system event occurs for a normal process 
and whenever a normal process is scheduled. 


When a system event occurs that affects a normal process, 
the scheduler increases the priority of the normal process 
(but not to more than the maximum priority of 15) and 
places the process at the tail of the queue for its new pri- 
ority. The amount of priority increment depends on the na- 
ture of the event. For example, the scheduler increases the 
priority of anormal process on the following events: 

e Terminal input completed. 

e Terminal output completed. 

e Resource available. 

e Wake, resume, delete request received. 


@ Nonterminal !/O completion, page fault completion, or 
other event. 


In this case, the terminal I/O events receive the highest pri- 
ority increments, so the system can be most responsive to 
the interactive terminal user. When the scheduler in- 
creases a normal processes’ priority, that process gets 
control of the processor if its new priority is higher than 
that of the process currently executing. 


Each time a normal process is scheduled, the scheduler 
decreases its priority by one (unless it is already in its base 
priority queue) and places it at the end of that priority 
queue. The effect of dynamically increasing and decreas- 
ing normal process priority ensures maximum overlap of 
computation and I/O. 


Swapping and the Balance Set 
It is the job of the swapper to keep the scheduler supplied 
with the highest priority executable processes in configu- 
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rations that do not have a sufficient amount of physical 
memory to keep all process working sets memory-resi- 
dent. The balance set is the set of all process working sets 
that are currently in memory. The swapper ensures that 
the balance set always contains the highest-priority execu- 
table processes by moving low-priority or nonexecutable 
memory-resident process working sets to a swap area on- 
disk and by moving high-priority or executable process 
working sets into memory. 


Swapping is a very efficient way of extending limited mem- 
ory resources when many processes are executing con- 
currently. Process working sets for small processes (less 
than 64 Kbytes or 128 pages) can be swapped in and out 
of memory in one disk-I/O operation. When paging ex- 
tends limited memory resources on a per-process basis 
and is limited to moving few pages in and out of memory, 
swapping balances the memory requirements of the sys- 
tem as a whole. 


The swapper is activated whenever a system event occurs 
that can make a nonresident process resident, a nonre- 
sident process executable, or a resident process nonexe- 
cutable. For example, a resident process might release 
sufficient memory to enable the swapper to move in a non- 
resident process. An I/O completion event might make a 
nonresident process executable. A resident process might 
enter a wait state and become nonexecutable. In any case, 
the swapper uses three conditions to determine which 
processes should be swapped in and which should be 
swapped out: 

e Which processes are executable and which are not (and 

the reason for the wait state). 


@ What the process priorities are. 
e Whether a process balance set quantum has expired. 


The balance set quantum effectively enforces a swapping 
rotation for compute-bound normal processes. Every nor- 
mal process is assigned a time quantum that provides a 
guaranteed minimum amount of time in which the process 
can perform useful work before it is eligible to be swapped 
out of the balance set. A process can be preempted many 
times before it has received its full quantum. It remains in 
the balance set until it completes its first quantum, unless 
a realtime process that is swapped out becomes executa- 
ble and no other processes can be swapped out to make 
room for the realtime process. 


VAX/VMS Process Control Services 

In addition to the VAX/VMS system services that enable 
processes to create, delete, suspend, resume, and wake 
other processes, or hibernate and wake themselves, a 
process can control the manner in which it is scheduled 
by: 

® Setting process swap mode. 

e Setting resource wait mode. 


A suitably privileged process can request that it not be 
swapped out of the balance set, even when it becomes in- 
active. This is useful for high-priority realtime processes 
that need to be activated rapidly when they become exe- 
cutable. 


Normally, when a process requires dynamic resources of 
the system and they are not available, the process enters a 
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User Interfaces to I/O Services 


wait state until the resources become available. Dynamic 
resources primarily include the buffer space needed for 
mailboxes, I/O requests, etc. A process can request to be 
notified when resources are not available and can take al- 
ternative action instead of entering a wait state. 


I/O PROCESSING 

The I/O-processing system consists of several modular in- 
terdependent components that enable programmers to 
choose the programming interface and processing 
method appropriate for their needs, without incurring run- 
time space or performance overhead for features not 
used. In addition, the |/O-request-processing software 
takes advantage of the hardware’s ability to overlap I/O 
transfers with computation, to switch contexts rapidly, and 
to generate interrupts on multiple priority levels to ensure 
the maximum possible data throughput and interrupt re- 
sponse. Figure 6-6 presents an overview of the major I/O- 
processing system components and their relationships. 


Programming Interfaces 

The I/O programming tools are the record-management 
system, VAX-11 RMS, for general purpose file and record 
processing and the Queue I/O system services for direct 
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I/O processing. Table 6-2 summarizes the programming 
interfaces. 


RMS (refer to the Information Management Facilities sec- 
tion) provides device-independent access to file-struc- 
tured I/O devices. The most general purpose type of ac- 
cess enables programs to process logical records; RMS 
automatically provides record blocking and unblocking. 


RMS users can also choose to perform their own record 
blocking on file-structured volumes such as disk and 
magnetic tape, either to control buffer allocation or to op- 
timize special record processing. Users who perform their 
own record blocking address blocks using a virtual block 
number (which is the number of the block relative to the 
file being processed) for volume-independent processing. 


The I/O system services provide both device-independent 
and device-dependent programming. Users perform their 
own record blocking on file-structured and non-file-struc- 
tured devices. Virtual block addressing is used on Files-11 
disk or ANSI magnetic-tape volumes. In addition, users 
with sufficient privilege can perform I/O operations using 
either logical or physical block addressing for defining 
their own file structures and accessing methods on disk 
and magnetic-tape volumes. 


The I/O system services also provide device-dependent 


programming of devices not supported by RMS, such as 
realtime interfaces. 


Ancillary Control Processes 

Both RMS and the I/O system services use the same I/O 
control processes, called ancillary control processes 
(ACPs), for processing file-structured I/O requests. An 
ACP provides file structuring and volume access control 
for a particular type of device. Typical ACP functions 
would include creating a directory entry or file, accessing 
or deaccessing a file, modifying file attributes, and delet- 
ing a directory entry or fileheader. There are three kinds of 
ACPs provided in the system: Files-11 disk, ANSI 
magnetic tape, and network communications link. 


The RMS and I/O system services programming interfaces 
are the same regardless of the ACP involved; but, since 
ACPs are particular to a device type, they do not have to 
be present in the system if the device is not present. There 
is one network ACP process for all DECnet network com- 
munications links in the system and none if the system is 
not in a network. 


Device Drivers 

Once the ACP sets up the information for file-structured 
I/O requests, a request can be passed on to a device 
driver. All non-file-structured I/O requests are passed 
directly to a device driver. 

A VAX/VMS driver: 

© Defines the peripheral device for the rest of the 
VAX/VMS operating system. 

Defines the driver for the operating-system procedure 
that maps and loads the driver and its device database 
into system virtual memory. 

Initializes the device (and/or its controller) at system 
startup time and after a power failure. 

Translates software requests for I/O operations into de- 
vice-specific commands. 

Activates the device. 

Responds to hardware interrupts generated by the de- 
vice. 

® Reports device errors. 

e Returns data and status from the device to software. 


Device drivers work in conjunction with the VAX/VMS op- 
erating system. The operating system performs all |/O 
processing that is unaffected by the particular specifica- 
tions of the target-device (device-independent) process- 
ing. When details of an I/O operation need to be translated 
into terms recognizable by a specific type of device, the 
operating system transfers control to a device driver (i.e., 
device-dependent processing). Since different peripheral 
devices expect different commands and setups, each type 
of device on VAX/VMS requires its own supporting driver. 


The VAX/VMS operating system contains device drivers 
for a number of standard DIGITAL-supported devices. 
These include both MASSBUS and UNIBUS devices. In 
addition, the user can write additional drivers for nonstan- 
dard UNIBUS devices. The VAX/VMS Guide to Writing an 
//O Driver manual provides detailed information on writ- 
ing, loading, and debugging drivers. 


I/O Request Processing 

All |1/O requests are generated by a Queue I/O (QIO) Re- 

quest system service. If a program requests RMS 

procedures, RMS issues the QIO Request system service 

on the program’s behalf. QIO Request processing is ex- 

tremely rapid because the system can: 

® Keep each device unit as busy as possible by minimizing 
the code that must be executed to initiate requests and 
to post request completion. 


® Keep each disk controller as busy as possible by over- 
lapping seeks with I/O transfers. 


The processor’s many interrupt priority levels improve in- 
terrupt response because they enable the software to have 
the minimum amount of code executing at high-priority 
levels by using low-priority levels for code-handling re- 
quest verification and completion notification. In addition, 
device drivers take advantage of the processor’s ability to 
overlap execution with I/O by enabling processes to exe- 
cute between the initiation of a request and its completion. 
User processes can queue requests to a driver at any time, 
and the driver immediately initiates the next request in its 
queue upon receiving an I/O completion interrupt. 


All access validation and checking takes place before an 
I/O request is actually queued. For file-structured I/O re- 


Table 6-2 
I/O Processing Interfaces 


METHOD PROGRAM I/O COMPONENTS PURPOSE 
INTERFACE 
Record I/O RMS requests RMS, ACP and Use Files-11 disk or ANS 
Driver magtape file structure, use RMS 
record access methods 
File |/O RMS OPEN and RMS for OPEN, Use Files-11 disk or ANS 
$QIO requests ACP and Driver magtape file structure, 
implement own record access 
methods 
Device I/O $QIO requests Driver Fast dumps to disk or magnetic 
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tape, foreign file structure 


quests, the Queue I/O Request system service obtains all 
the virtual-block mapping and volume-access checking 
information from the ACP or directly from tables created 
by the ACP. For example, on virtual-block I/O requests for 
multivolume files, the system service obtains from the 
ACP’s tables the mapping information that enables it to 
queue requests to different drivers when the user’s I/O re- 
quest involves a transfer that spans volumes. The Queue 
I/O Request system service also checks the validity of the 
function requested (read, write, rewind, etc.) for the partic- 
ular device. Because all access validation and function 
checking is performed before the request is queued, the 
driver has little to do to initiate a request. 


Once the system service has verified the I/O request, it 
raises the interrupt priority level to that of the driver. The 
only activity it has to perform at this level is a test to see if 
the driver is busy. If the driver is not busy, it calls the 
driver. Otherwise, it queues the request according to the 
priority of the requesting process and immediately returns 
to the user process. 


When the driver is called, it initiates the request and re- 
turns to the user process. Because disk seeks do not re- 
quire the controller once they are initiated, if a disk driver 
receives a seek request and the controller is currently 
busy with an I/O transfer request on some other disk unit, 
the driver queues the request so that the controller will ini- 
tiate the seek request before any pending I/O transfers 
when it has finished the current transfer. 


When the device subsequently generates its interrupt at 
the hardware interrupt priority level, the interrupt dis- 
patcher calls the appropriate interrupt service routine. An 
interrupt service routine simply saves the device con- 
trol/status registers, requests a software interrupt at the 
driver's interrupt priority level, and returns to the interrupt 
dispatcher (which is then free to scan for unit attentions). 
Because a disk controller cannot generate interrupts on 
any unit performing a seek until the current transfer com- 
pletes, the interrupt dispatcher will also dispatch seek 
completion when dispatching a disk I/O transfer comple- 
tion interrupt. 


When the driver receives the completion interrupt, it pre- 
pares the I/O completion status for the requester, and re- 
quests a software interrupt. The driver is then free to 
process another request in its queue and, if the queue is 
not empty, the driver begins again. All |/O completion noti- 
fication takes place outside the driver, minimizing the in- 
terrequest idle time. The I/O post routine notifies the proc- 
ess of |/O completion and releases or unlocks buffers. 


COMPATIBILITY MODE OPERATING ENVIRONMENT 
The processor can execute user-mode PDP-11 instruction 
streams in the context of a process. The operating system 
supplements this feature by substituting its functionally 
equivalent system services for many of the RSX-11M oper- 
ating system executive directives that user-mode tasks 
may call. This enables the system to execute such nonpri- 
vileged RSX-11M task images as: 

e The PDP-11 MACRO assembler. 

e The PDP-11 FORTRAN IV/VAX to RSX compiler. 


e The RSX program development and file management 
utilities, including the taskbuilder, text editor, etc. 
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In addition, the operating system supports the RMS-11 
and RMS-11K record management services procedures 
for compatibility-mode programs. Program and data files 
can therefore be transported between VAX and RSX sys- 
tems. 


In addition to DCL, DIGITAL’s standard command lan- 
guage, the operating system also supports the RSX-11M 
Monitor Console Routine (MCR) commands, either typed 
directly on a terminal, or submitted as indirect command 
files. 


User Programming Considerations 

Any PDP-11 FORTRAN IV/VAX-to-RSX, or PDP-11 MA- 
CRO program can be executed in compatibility mode, 
provided that it is first linked by the RSX-11M taskbuilder 
and that the resulting task image meets the following re- 
quirements: 


e It must not execute PDP-11 privileged instructions. 
e It must have been built for a mapped system. 
e It must not depend on 32-word memory granularity. 


e It must not use the privileges that enable it to map into 
the executive or I/O page. 


e It must not use memory management executive direc- 
tives. 


e It must not rely on environmental features of RSX-11M 
that VAX/VMS does not support (partitioning or signifi- 
cant events). 


e It must not use DECnet. 
e It must access only ODS-| volumes. 


The task can be privileged to issue directives other than 
memory management directives — direct volume access 
using the QIO request executive directive, for example. 
IAS or RSX-11D tasks that meet these requirements can 
also be executed. They must first be built with the RSX- 
11M taskbuilder. For programs that do not meet these re- 
quirements, VAX/VMS provides the program develop- 
ment utilities (for example, the MACRO assembler and the 
taskbuilder) for modifying programs to execute in compat- 
ibility mode. 

For most RSX-11M executive directives, the native-mode 
operating system executes a functionally equivalent 
system service. In most cases, the system service dupli- 
cates the function. For example: 


e A checkpoint enable/disable directive is interpreted as 
the set swap-mode system service. 


e The send/receive directives are translated into mailbox 
write/read system services. Native-mode and compati- 
bility-mode images can communicate using mailboxes. 


e The event-flag directives are, for the most part, identical. 
Native-mode and compatibility-mode images can com- 
municate using common event flags, provided they are 
in the same group. 

e A Logical Unit Number (LUN) assignment directive is 
interpreted as a channel assignment for the appropriate 
device. 


In some cases, the operating system cannot duplicate the 

function, but it does what it can to let a program continue. 

For example: 

e A task image is allowed to declare a significant event, 
but the directive is ignored. 


e A set priority directive is ignored, since the scheduling 
priority ranges are different. To run at a given priority, 
the image must be run in the context of a process given 
that priority. 


For the most part, however, many RSX-11M and 
VAX/VMS program environment characteristics corre- 
spond. For example, tasks can hibernate, receive asyn- 
chronous system traps, and schedule wake requests. Syn- 
chronous system-trap routines can be declared as 
condition handlers for trace traps, breakpoint traps, illegal 
instruction traps, memory protection violations, and odd 
address errors. 


File System and Data Management 

Both RSX-11M and VAX/VMS recognize User Identifica- 
tion Codes as protection mechanisms. UICs provide the 
default-user file directory in RSX-11M systems, while, in 
VAX/VMS, a UIC is not necessarily associated with an ac- 
count name or default directory name. UlC-based file pro- 
tection, however, is much the same in both systems; that 
is, it is used in determining read, write, and delete privi- 
leges for system, owner, group, and world. 


Tasks can use any of the RSX data management services 
including File Control Services (FCS), RMS-11, and RMS- 
11K. Special versions of FCS and RMS-11/RMS-11K are 
supplied with VAX/VMS. A compatibility-mode task built 
on VAX/VMS is thus provided with the full file-naming ca- 
pabilities of VAX/VMS, including logical names and mul- 


tilevel directories. However, update of a file by multiple 
tasks is not supported. 


Both magnetic tape and Files-11 disk volumes can be 
transported between systems. VAX/VMS can read and 
write both Files-11 Level 1 disk structures (ODS-1) and the 
Level 2 disk structures (ODS-2). The Extend access pro- 
tection field in ODS-1 is used for Execute access protec- 
tion in ODS-2. While reading files stored on ODS-1 vol- 
umes, therefore, this protection field is ignored. 


Command Languages 

In addition to DCL, VAX/VMS users can select the MCR 

command interpreter, which allows them to execute a lan- 

guage (VAX/VMS MCR) that is similar to the RSX-11M 

MCR command language. Selecting the MCR command 

interpreter allows the VAX/VMS user to perform the fol- 

lowing: 

e Run RSX-11M images and VAX-11 images. 

e Use RSX-11M components for RSX-11M program de- 
velopment — for example, MACRO-11 or the task- 
builder. 


e Use VAX/VMS components for native program 
development — for example, VAX-11 MACRO or the 
linker. 


e Execute RSX-11M indirect command files. (The 
VAX/VMS user can use this facility to execute those files 
required for RSX-11M or RSX-11S system generation.) 


VAX/VMS will associate the MCR command interpreter 
with a process, if “MCR” is the default command interpre- 
ter named in the user’s authorization file entry or if the user 
specifies /CLI=MCR following “username” in the LOGIN 
statement (overriding the default). 
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The 
Languages 


VAX/VMS includes a complete program-development environment for a wide 
range of languages. In addition to the native assembly language, VAX/VMS of- 
fers many optional high-level programming languages commonly used in de- 
veloping both scientific and commercial applications: FORTRAN, COBOL, BA- 
SIC, C, PL/I, PASCAL, CORAL 66, and BLISS-32. It provides the tools 
necessary to write, assemble or compile, and link programs, as well as build 
libraries of source, object, and image modules. 


Programmers can use the system for development while production is in pro- 
gress. They can interact with the system online, execute command procedures, 
or submit command procedures as batch jobs. Novice programmers can learn 
the system quickly because the command language accepts standard defaults 
for invoking the editors, compilers, and linker. Experienced programmers will 
appreciate the flexibility and control each tool offers. 


INTRODUCTION 

VAX/VMS provides a complete program-development en- 
vironment. In addition to the assembly language, MACRO, 
it offers the optional higher-level languages commonly 
needed in engineering, scientific, commercial, instruc- 
tional, and implementation applications—FORTRAN, CO- 
BOL, BASIC, C, PL/I, PASCAL, CORAL 66, and BLISS-32. 
VAX/VMS provides the tools to write, assemble or com- 
pile, and link programs, as well as to build libraries of 
source, object, and image modules. User applications can 
employ more than one language, and the ability of lan- 
guages to call one another allows concatenation of appli- 
cation segments written in a variety of languages, provided 
they satisfy certain criteria. 


These native-mode language processors produce native 
object code and take advantage of the native instruction 
set and 32-bit architecture of the VAX hardware. 


In addition, there is the host development-mode program- 
ming environment that provides support for PDP-11 FOR- 
TRAN IV/VAX to RSX, BLISS-16, and MACRO-11. These 
languages produce compatibility-mode object code. 


VAX COMMON LANGUAGE ENVIRONMENT 

An important feature provided by VAX is a “common lan- 
guage” environment, that is, the VAX languages adhere to 
a specific set of standards, including: 

e Symbolic debugger interface. 

e Use of the symbolic traceback facility. 

e Use of the Common Runtime library. 


e Conformance to the VAX calling standard that allows 
calls among any set of VAX languages to VAX/VMS sys- 
tem services and to SORT and FMS subroutines. 


@e Common handling of exceptions. 
e Use of VAX-11 RMS for record handling. 


Symbolic Debugger Interface 

VAX/VMS provides facilities to aid the debugging of pro- 
grams written in native mode. It accomplishes this via a 
program known as the interactive symbolic debugger. The 
debugger can be linked with a native program image to 
control image execution during development. It can be 
used interactively or can be controlled from a command 
procedure file. The debugging language is similar to the 
VAX/VMS command language. Expressions and data 
references are similar to those of the source language 
used to create the image being debugged. Debugging 
statements can be conditionally compiled. 


Debugging commands include the ability to start and inter- 
rupt program execution, to step through instruction se- 
quences, to call routines, to set break or trace points, to 
set default modes, to define symbols, and to deposit, ex- 
amine, or evaluate virtual memory locations. 


Symbolic Traceback Facility 

VAX/VMS supports the Symbolic Traceback Facility. This 
is aruntime facility that aids programmers in finding errors 
by describing the call sequences that occurred prior to the 
error. The traceback facility is automatic; it does not 
require that any special qualifiers be included with the 
FORTRAN or LINK commands, although it can be sup- 
pressed by specifying NOTRACE with the LINK command. 
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When an error condition is detected, the error message is 
displayed by the runtime library that indicates the nature 
of the error and the address at which the error occurred 
(user PC). This is followed by traceback information that is 
presented in inverse order to the calls. For each call frame, 
traceback lists module name, routine name, source-pro- 
gram line, and absolute and relative PC. Using this infor- 
mation, the programmer can usually locate the source of 
the error in a relatively short period of time. 


Common Runtime Library 

The VAX-11 Common Runtime Procedure Library 
contains sets of general purpose and language-specific 
procedures. User programs call these procedures to per- 
form specific tasks required for program execution. Both 
VAX-11 MACRO and native-mode high-level language 
programmers can use any of the Runtime Library pro- 
cedures in any combination. Because all procedures fol- 
low the same programming standards and make no con- 
flicting execution assumptions, a language-independent 
common runtime environment is provided for user pro- 
grams. Such an environment encourages a user program 
to be composed of procedures written in different lan- 
guages and, therefore, increases programming flexibility. 


VAX Calling Standard 

The VAX-11 procedure-calling standard defines and sup- 
ports the mechanisms for passing arguments between 
modules of major VAX-11 software subsystems such as 
languages, VAX-11 RMS, and the VAX/VMS operating 
system. The standard facilitates the calling of a procedure 
written in one language from a program written in another 
language. 


Exception Handling 

The mechanisms defined by the VAX-11 calling standard 
are also used by the condition-handling facility to signal 
the occurrence of exceptions detected by hardware or 
software. 


VAX-11 RMS 

VAX-11 Record Management Services (RMS) is the tech- 
nique programmers use to handle record I/O within pro- 
grams. VAX-11 RMS routines are system routines that 
provide an efficient and flexible means of handling files 
and their data, and allowing sharing of files across lan- 
guages. All VAX languages do I/O through RMS, so files 
written by one application can be read and used by 
another application, even if it is written in a different lan- 
guage. Typically, VAX-11 RMS routines allow the pro- 
grammer to create a file and: 

e Accept new input. 

e Read or modify data. 


e Produce output in a meaningful form. 


High-level language programmers normally use the 1/O fa- 
cilities of their particular language to perform record and 
file operations. These operations are implemented using 
the VAX-11 RMS facilities. VAX-11 MACRO programmers 
can use the VAX-11 RMS routines directly within their pro- 
grams. 


VAX-11 RMS routines are an integral part of the operating 
system. The programmer need not perform any special 
linking or declaring of global entry points for the routines. 


Furthermore, calls to VAX-11 RMS routines are consistent 
with the VAX calling standard. 


The elements of the common language environment are 
discussed more fully as they apply to each individual VAX 
language. Introduced below are each of the VAX-sup- 
ported languages, their attributes, characteristics, and 
sample coding. 


VAX-11 FORTRAN 

VAX-11 FORTRAN is an optional language-processing 
system for VAX/VMS. It conforms at the full language level 
to the American National Standard Institute FORTRAN 
X3.9-1978 (commonly called FORTRAN-77). This compiler 


is upward-compatible with the PDP-11 FORTRAN IV and 
PDP-11 FORTRAN-77 languages. Further, it provides op- 
tional switch-selectable support for programs conforming 
to the previous ANSI standard, X3.9-1966. Thus, programs 
written for older compilers both on PDP-11 systems and 
on other vendors equipment can be easily transported to 
VAX-11 systems. The VAX-11 FORTRAN compiler per- 
forms the following functions: 

e Produces highly optimized VAX native object code. 


e Makes use of the VAX floating point and character string 
instructions. 


e Produces sharable code and is itself sharable. 


Table 7-1 


Language Extensions to ANSI FORTRAN-77, 
X3.9-1978 


31-character symbolic Symbolic names used to 


Data initialization in Variables can be assigned 


names 


CALL extensions 


Hexadecimal and octal 
constants and field 
descriptors 


Bit Manipulation 


DO WHILE/END DO 


identify programs, sub- 
programs, external func- 
tions and subroutines, 
COMMON blocks, vari- 
ables, arrays, symbolic 
constants, and statement 
functions can be longer 
than the standard six 
characters. Symbolic 
names can include letters, 
digits, dollar sign, and un- 
derscore; however, the 
first character in name 
must be a letter. 


Permit interfacing to 
VAX/VMS system service 
procedures using the 
VAX-11 calling standards. 


Both octal and hexadeci- 
mal constants can be ex- 
pressed in DATA state- 
ments. No conversion of 
the defined value (such as 
sign extension) is per- 
formed. The Z field de- 
scriptor in FORMAT state- 
ments enables a program 
to read and write 
hexadecimal digits that 
are stored in an internal 
format in an I/O list ele- 
ment. 


Intrinsic functions used to 
set, clear, test, extract, or 
move bits. 


Structured looping-con- 
trol constructs. 


type-declaration state- 
ments 


INTEGER data type de- 
faults 


Additional data types and 
type declaration state- 
ments (DOUBLE COM- 
PLEX, COMPLEX*16, and 
CHARACTER*n are VAX- 
11 FORTRAN only) 


Indexed File |/O 


Keyed READ 


initial values in type 
declaration statements. 


A compiler command 
specification allows all 
INTEGER and LOGICAL 
declarations without ex- 
plicit length specifications 
to be considered as INTE- 
GER*2 and LOGICAL*2 or 
INTEGER*4 or LOGICAL* 
4, respectively. 


BYTE, LOGICAL*1, 
LOGICAL*2, 

LOGICAL, LOGICAL*4, 
INTEGER*2, 

INTEGER, INTEGER*4, 
REAL, REAL*4, 
DOUBLE PRECI- 

SION, REAL*8, REAL * 
16 

COMPLEX, COMPLEX’*8, 
DOUBLE COMPLEX, 
COMPLEX*16, 
CHARACTER’n 


NOTE 
Names appearing on the 
same line above are syno- 
nyms. Those in boldface 
are the ANSI standard 
ones. 


Extensions are provided 
to allow FORTRAN lan- 
guage access to RMS 
ISAM files. 


Key types: INTEGER*2, 
INTEGER*4, CHARAC- 
TER with generic, and ap- 
proximate-key match. 


Indexed File WRITE 


REWRITE statement 


DELETE statement 


UNLOCK statement 


Logical operations on 
integers 


INCLUDE statement 


VAX-11 FORTRAN 
Additional data types 


Additional I/O statements 


DO control variable data 
types 
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New records can be writ- 
ten to ISAM files with the 
write statements. 


Existing records in ISAM 
files can be modified with 
the REWRITE statement. 


Existing records can be 
deleted from ISAM or re- 
lative files with the DE- 
LETE statement. 


Single-record locking (in 
the VAX environment) and 
bucket-level locking (in 
the PDP-11 environment) 
for shared file applica- 
tions involving relative 
and indexed organization 
files. 


The logical operators 
-AND., .OR., .NOT., .XOR., 
and .EQV. can be applied 
to integer data to perform 
bit masking and manipu- 
lation. 


The INCLUDE statement 
incorporates FORTRAN 
source text from a sepa- 
rate file into a FORTRAN 
program. 


Array subscripts using 
general expressions of 
any 

numeric data type 


End-of-Line comments 


Conditional compilation of 
debugging statements 


Default FORMAT width 


Any arithmetic expression 
can be used as an array 
subscript. If the value of 
the expression is not an 
integer, it is converted to 
integer format. 


Any FORTRAN statement 
can be followed, in the 
same line, bya comment 
that begins with an excla- 
mation point. 


Statements that are in- 
cluded in a program for 
debugging purposes can 
be so designated by the 
letter D in Column 1. 
Those statements are 
compiled only when the 
associated compiler com- 
mand option is set. They 
are treated as comments 
otherwise. 


The programmer can 
specify input or output 
formatting by type and 
default width, and preci- 
sion values will be sup- 
plied. 


Table 7-2 lists the features of FORTRAN-77. 


Table 7-2 


FORTRAN-/77 Features 


The data type INTEGER*4 
provides a sign plus 31 
bits of precision. IN- 
TEGER*4 allows a greater 
range of values to be rep- 
resented than INTEGER* 
2. Both data types can be 
used in the same pro- 
gram. 


READ (u’r,fmt) and WRITE 
(u’r,fmt) provide input and 
output to direct access 
files. 


The control variable of a 
DO statement can bea 
REAL or DOUBLE-PRECI- 
SION variable, as well as 
an INTEGER*2 or INTE- 


Additional data type 


IF THEN ELSE statements 


GER*4 variable. The ini- 
tial, terminal, and incre- 
ment parameters, which 
can be of any data type, 
are converted before use 
to the type of the control 
variable if necessary. 


The data type CHARAC- 
TER permits manipulation 
of strings of ASCII charac- 
ters expressed as con- 
stants, variables, arrays, 
substrings, symbolic 
names, or functions. 


These FORTRAN-77 
block-IF statements are 
provided: IF, ELSE IF, 
ELSE, and ENDIF. These 
structured programming 


Standard CALL facility 


ENTRY statement 


PARAMETER statement 


Generic function selection 


Array dimension bounds 


List-Directed I/O state- 
ments 


Additional I/O statements 


End-of-file or Error- 
Condition transfer 
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statements provide more 
readable and reliable 
methods for expressing 
conditional statement ex- 
ecution. 


Provides standard argu- 
ment definitions for called 
procedures. 


ENTRY statements can be 
used in SUBROUTINE 
and FUNCTION subpro- 
grams to define multiple 
entry points in a single 
program unit. 


PARAMETER statements 
can be used to give sym- 
bolic names to constants. 


Function selection by ar- 
gument data type is pro- 
vided for many FORTRAN 
library functions. 


Lower bounds as well as 
upper bounds of the array 
dimension can be speci- 
fied in array declarators. 
The value of the lower- 
bound dimension declar- 
ator can be negative, zero, 
or positive. 


The READ (u,*), WRITE 
(u,*), TYPE*, ACCEPT*, 
and PRINT* statements 
provide list-directed, or 
“free format,” I/O without 
requiring a FORMAT 
specification. 


OPEN and CLOSE state- 
ments provide file control 
and attribute definition. 
ACCEPT, TYPE, and 
PRINT statements provide 
device-oriented I/O. EN- 
CODE and DECODE 
statements provide mem- 
ory-to-memory format- 
ting. DEFINE FILE, READ 
(u’r), WRITE (u’r), and 
FIND (u’r) provide unfor- 
matted direct access I/O 
that allows the FORTRAN 
programmer to read and 
write files written in any 
format. 


The specifications END=n 
and ERR=n (wherenisa 
statement label) can be 
included in any READ or 


Additional data type 


IMPLICIT declaration 


Implicit NONE statement 


DO loop iteration count 


Array dimensions 


Character literals 


Mixed-mode expressions 


WRITE statement to trans- 
fer control to the specified 
statement upon detection 
of an end-of-file or error 
condition. The ERR=n op- 
tion is also permitted in 
the ENCODE and DE- 
CODE statements, allow- 
ing program control of 
data format errors. 


The byte data type (key- 
word LOGICAL*1 or 
BYTE) is useful for storing 
small integer values as 
well as for storing and 
manipulating character 
information. 


The IMPLICIT statement 

has been added to rede- 

fine the implied data type 
of symbolic names. 


Overrides all default im- 
plicit tapes. All data types 
of all symbolic names 
must be explicitly de- 
clared. When used, no 
other IMPLICIT statement 
can be included in the 
program unit. 


The terminal and incre- 
ment parameters can be 
modified within a DO loop 
without affecting the itera- 
tion count. The number of 
times a DO loop is exe- 
cuted is determined at the 
initialization of the DO 
statement and is not ree- 
valuated during succes- 
sive executions of the 
loop. Consequently, the 
number of times the loop 
is executed will not be af- 
fected by changing the 
variables used in the DO 
statement. 


Arrays can have up to se- 
ven dimensions. 


Character strings 
bounded by apostrophes 
can be used in place of 
Hollerith constants. 


Mixed-mode expressions 
can contain any data type, 
including complex and 
byte. 


Table 7-2 (Cont.) 


General expression DO 
and GO TO parameters 


General expressions are 
permitted for the initial 
value, increment, and limit 
parameters in the DO 
statement, and as the 
control parameter in the 
computed GO TO state- 
ment. 


The value of the DO state- 
ment increment parame- 
ter can be negative. 


DO increment parameter 


File Manipulation 

OPEN and CLOSE statements extend the file-manage- 
ment characteristics of the FORTRAN language. An OPEN 
statement can contain specifications for file attributes that 
direct file creation or subsequent processing. Attributes 
include: file organization (sequential, relative, indexed), 
access method (sequential, direct, keyed), protection 
(read-only, read/write), record type (formatted, unformat- 
ted), record size, and file allocation or extension. The pro- 
gram can also specify whether or not the file can be shared 
and whether the file is to be saved or deleted when closed. 
The OPEN statement can contain an ERR keyword that 
specifies the statement to which control is transferred if an 
error is detected during OPEN. 


Of particular interest is the VAX-11 FORTRAN support for 
the Indexed Sequential Access Method (ISAM), a powerful 
keyed input/output file access capability. VAX-11 FOR- 
TRAN is able to create, read, and write indexed (and rela- 
tive) files. In addition, FORTRAN is able to reference a re- 
lative or indexed file already created by another language 
(for instance, COBOL), provided the file and data formats 
and the key information are compatible. 


Simplified I/O Formats 

List-directed and NAMELIST-directed input and output 
statements provide a method for obtaining simple sequen- 
tial formatted input or output without the need for FOR- 
MAT statements. Using list-directed input, values are read, 
converted to internal format, and assigned to the elements 
of the I/O list. On output, values in the I/O list are con- 
verted to characters and written in a fixed format 
according to the data type of the value. 


The NAMELIST statement and the associated forms of in- 
put/output statements provide a simplified means of 
transmitting lists of data to and from files. The list of items 
that can be transferred is specified in a NAMELIST state- 
ment. The associated input/output statement refers to the 
list of items to be transferred by including the name of the 
NAMELIST as a control parameter. NAMELIST I/O state- 
ments do not contain explicit I/O lists. Therefore, it is pos- 
sible to reference a single name in a simple input/output 
statement and get an effect similar to a statement with a 
long list and a reference to a complicated format 
statement. 
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The statement label list is 
an assigned GO TO is op- 
tional. 


Optional statement label 
list 


General expressions in 
I/O lists 


General expressions are 
permitted in I/O lists of 
WRITE, TYPE, and PRINT 
statements. 


Some characteristics of VAX-11 FORTRAN are described 
below. 


Character Data Type 

A program can create fixed-length CHARACTER variables 
and arrays to store ASCII character strings. The VAX-11 
FORTRAN language provides a concatenation operator, 
substring notation, CHARACTER relational expressions, 
and CHARACTER-valued functions. CHARACTER con- 
stants consisting of a string of printable ASCII characters 
enclosed in string quotes can be assigned symbolic 
names using the PARAMETER statement. Operations that 
use CHARACTER strings are more efficient and easier to 


SUBROUTINE REVERSE(S) 
CHARACTER T, S*(*) 


J = LEN(S) 

DO 1=1, J/2 
T = SiI:l) 
S(I:1) = S(J:J) 
S(J:J) = T 
J=J-1 

ENDDO 

END 


SUBROUTINE FIND SUBSTRINGS(SUB, S) 
CHARACTER‘*(*) SUB, S 
CHARACTER*132 MARKS 
[= 
MARKS ="? 
J = INDEX(S(I:), SUB) 
IF (J .NE. 0) THEN 
l=1+(J—1) 
MARKS(I:1) = '#’ 
l=14+1 
IF (I .LE. LEN(S)) GO TO 10 
ENDIF 


WRITE(6,91) S, MARKS 
FORMAT( 2(/1X, A)) 
END 


10 


91 


Figure 7-1 
FORTRAN CHARACTER 
Data Type Program 


use than their analogs that use arithmetic data types. 
VAX/VMS provides a set of character-manipulation pro- 
cedures that are FORTRAN-callable (e.g., LIBSLOCC: lo- 
cate a character in a string). 


Figure 7-1 illustrates two VAX-11 FORTRAN subroutines. 
This figure illustrates the use of the FORTRAN CHARAC- 
TER data type and some of the VAX-11 FORTRAN 
extensions to ANSI FORTRAN-77. The first subroutine, 
which reverses a character string, illustrates CHARACTER 
declarations (both fixed-length and passed-length), the in- 
trinsic function LEN, substring manipulation, and the 
ENDDO statement. The second subroutine locates a sub- 
string of a character string and marks the starting position 
of the substring. This subroutine illustrates CHARACTER 
declarations (both fixed-length and passed-length), as- 
signments of character values to variables, the intrinsic 
function INDEX, substring manipulation, and the FOR- 
TRAN-77 block IF statement. 


Source Program Libraries 

The INCLUDE statement provides a mechanism for writing 
modular, reliable, and maintainable programs by eliminat- 
ing duplication of source code. A section of program text 
that is used by several program units, such as a COMMON 
block specification, can be created and maintained as a 
separate source file. All program units that reference the 
COMMON block then merely INCLUDE this common file. 
Any changes to the COMMON block will be reflected auto- 
matically in all program units after compilation. INCLUDE 
also allows you to include modules from text libraries. 
VAX-11 FORTRAN provides a text library that contains 
FORTRAN source for many VAX/VMS system symbols. 


Calling External Functions and Procedures 

FORTRAN programs can call subroutines written in any 
other VAX language and also system services, using the 
VAX-11 procedure-calling standard. Special operators ex- 
ist for passing arguments by immediate value, by refer- 
ence, or by descriptor. A special operator also exists for 
obtaining the location of argument values used by the sys- 
tem services procedures. 


Sharable Programs 

The FORTRAN language can be used to create sharable 
programs. FORTRAN subprograms can also be used to 
create sharable-image libraries that can be available to 
any program written in a native programming language. 


Cross Reference Listings 

The VAX-11 FORTRAN compiler optionally provides a rou- 
tine cross-reference listing. This gives information about 
the use of names in the routines, including the line num- 
bers of the lines in which the names appear. 


Diagnostic Messages 

Diagnostic messages are generated when an error or po- 
tential error is detected. Errors detected during compila- 
tion are reported by the compiler; these include source- 
program errors such as misspelled variable names, miss- 
ing punctuation marks, etc. 


Source program diagnostic messages are classified ac- 
cording to severity: F (Fatal), E (Error), or W (Warning). F- 
class messages indicate errors that must be corrected be- 
fore compilation can be completed. Object code is not 
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produced. E-class messages indicate that an error was 
detected that is likely to produce incorrect results; how- 
ever, an object file is generated. W-class messages are 
produced when the compiler detects acceptable but non- 
standard syntax or when it corrects a syntactically incor- 
rect si ment. The message indicates the possibility of 
trouble in executing the program. 


The VAX-11 FORTRAN compiler optionally produces diag- 
nostic messages for VAX FORTRAN extensions to ANSI 
FORTRAN-77. This flagger can check both syntax and/or 
source form extensions. 


Compiler Operations and Optimizations 

The VAX-11 FORTRAN compiler accepts sources written 
in the FORTRAN language and produces an object file that 
must be linked prior to execution. The compiler generates 
VAX-11 native machine-language code. Figure 7-2 is an il- 
lustration of VAX-11 FORTRAN code and its equivalent 
VAX-11 MACRO code. 


During compilation, the compiler performs many code op- 
timizations. The optimizations are designed to produce an 
object program that executes in less time than an equi- 
valent nonoptimized program would. Also, the optimiza- 
tions are designed to reduce the size of the object 
program. 


The VAX-11 FORTRAN compiler performs the following 

optimizations: 

e Constant folding — Constant expressions are evaluated 
at compile time. 


e Compile-time constant conversion. 


e Compile-time evaluation of constant subscript expres- 
sions in array calculations. 

e Constant pooling — Only a single copy of a constant is 
allocated storage in the compiled program. Constants 
that can be used as immediate-mode operands are not 
allocated storage. For example, logical, integer, and 
small floating-point constants are generated as immedi- 
ate-mode or short-literal operands wherever possible. 

e Inline expansion of statement functions. 

e Argument list merging — If two function or subroutine 
references have the same arguments, a single copy of 
the argument list is generated. 

e Branch instruction optimizations for arithmetic or logical 
IF statements. 

e Elimination of unreachable code — An optional warning 
message is issued to mark unreachable statements in 
the source-program listing. 

e Recognition and replacement of common subexpres- 
sions. 

e Removal of invariant computations from DO loops. 

e Local register assignment — Frequently referenced var- 
iables are retained (when possible) in registers to re- 
duce the number of load and store instructions. 

e Assignment of frequently used variables and 
expressions to registers across DO loops. 

e Reordering expression evaluation to minimize the num- 
ber of temporary registers required. 

e Delaying negation/not to eliminate unary complement 
operations. 


11-Apr-1981 11:56:00 VAX-11 FORTRAN V3.0-1 Page 1 
0001 SUBROUTINE RELAX2(EPS) 

0002 PARAMETER M=40, N=60 

0003 DIMENSION X(0:M,0:N) 

0004 COMMON X 

0005 LOGICAL DONE 

0006 1 DONE = .TRUE. 

0007 DO 10 J = 1,N—1 

0008 DO 10! = 1,M—1 

0009 XNEW = ( X(I—1,J)+X(I4+1,J)+X(I,d—1) +X (Id +1) )/4 

0010 IF (ABS(XNEW—X(I,J)) .GT. EPS ) DONE = .FALSE. 

0011 10 X(I,J) = XNEW 

0012 IF (NOT. DONE) GO TO 1 

0013 RETURN 

0014 END 

1-Apr-1981 11:56:00 VAX-11 FORTRAN V3.0-1 Page 2 


0000 
0000 


0000 
0000 
0000 
0002 


0009 
0009 


000C 
OOOF 
0016 


0016 
0019 
001D 


001D 
0021 

0029 
002F 
0035 


003D 
0042 
0047 
004B 
004D 
004F 


004F 
0053 
0057 
005B 
OOSF 
0063 


0067 


006A 


x: 


RELAX2:: 


L$1: 


L$2: 


L$3: 


wTITLE 
IDENT 


-PSECT 


.PSECT 


.WORD 
MOVAL 


MNEGL 


MOVL 
MOVAL 


MOVL 
MULL3 


ADDL3 
ADDF3 
ADDF2 
ADDF2 
MULF3 


SUBF3 
BICW2 
CMPF 
BLEQ 
CLRL 


MOVL 


AOBLEQ 
AOBLEQ 


MOVL 
MOVL 
MOVL 


BLBC 


RET 
-END 


RELAX2 
01 


$BLANK 


$CODE 


*M<IV,R5,R6,R7,R8,R9,R10,R11> 
$LOCAL, R11 


; 0006 


#1, DONE (R11) 
- 0007 

#1,R6 

$BLANK, R5 


; 0008 
#1, R9 
#41, R6, R7 


0009 
R9, R7, R10 
X+4(R5)(R10), X—4(R5)[R10], RO 
X—164(R5)[R10], RO 
X+164(R5)[R10], RO 
#4X3F80, RO, R8 
0010 
X(R5)[R10], R8, RO 
#*X8000, RO 
RO, tEPS(AP) 
L$3 
DONE(R11) 


0011 
R8, X(R5)[R10] 
#39, R9, L$2 
#59, R6, L$1 
R6, J(R11) 
R8, XNEW(R11) 
RQ, 1(R11) 
0012 
DONE(R11), .1 
0013 


Figure 7-2 


Page 1 above illustrates, as a VAX-11 FORTRAN sub- 
routine, a relaxation function often found in engineering 
applications. This particular example is a planar (2-di- 
mensional) function that can be used to obtain the val- 
ues of a variable at coordinates on a surface, for in- 
stance, temperatures distributed across a metal plate. 
The algorithm illustrated here locates the array element 
values relative to a given point in the plane. 


Page 2 contains the equivalent VAX-11 MACRO 
assembly code for this VAX-11 FORTRAN subroutine. 
The line numbers in the comment just to the left of this 
paragraph refer to the lines in the VAX-11 FORTRAN 
subroutine listing above. Several VAX-11 FORTRAN 
compiler optimizations are illustrated, including global 
and local register assignment, removal ofinvariant 
computations from the DO loop, recognition of common 
subexpressions, branch instruction optimizations, in- 
line ABS function, and peephole optimization. 


The code for lines 7 and 8 contains the global register 
assignments for the function. The multiply statement 
just preceding the code for line 9 is an invariant compu- 
tation (J*41) removed from the DO loop. DO loop con- 
trol is provided by the Add One and Branch Less Than 
or Equal (AOBLEQ) instructions in the code for line 117. 


The code for line 9 evaluates the common subexpres- 
sion for the computation. The code contains a local reg- 
ister assignment (R10), and uses 2- and 3-operand 
instructions and context switching ({R10]) to calculate 
an array element value. The last instruction for line 9is a 
peephole optimization that increases execution speed 
by using a “multiply by .25” in place of the FORTRAN 
statement’s “divide by 4.” 


VAX-11 FORTRAN Program 
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e Flow-Boolean optimizations. 


e Jump/Branch instruction resolution — The Branch in- 
struction is used wherever possible to eliminate unne- 
cessary Jump instructions. This reduces code size. 


e Peephole optimizations — The code is examined on an 
operation-by-operation basis to replace sequences of 
operations with shorter and faster equivalent opera- 
tions. 


Debugging Facilities 

VAX-11 FORTRAN debugging facilities include diagnostic 
messages, conditional compilation flags, and access to the 
VAX/VMS DEBUG program. The DEBUG program lets the 
programmer set breakpoints and tracepoints and examine 
and modify the contents of locations dynamically when ex- 
ecuting the program. 


DEBUG understands FORTRAN data type representations 
and syntax. It can examine and deposit locations using flo- 
ating-point representation and can symbolically reference 
FORTRAN symbols, statement labels, and line numbers. It 
can display FORTRAN source statements and can also 
symbolically reference arrays, for example: 


EXAMINE A(I,J+3) 


When debugging VAX-11 FORTRAN programs, the pro- 
grammer can disable optimizations that would remove un- 
referenced statement labels, FORMAT statement labels, 
and immediately referenced labels. This ensures that all 
statement labels are available to the debugger. 


Symbolic Traceback 

Figure 7-3 illustrates a source VAX-11 FORTRAN program 
and the symbolic traceback facility supported by 
VAX/VMS. (Note that some of the entries in the list show 
relative and absolute PC, but no corresponding values for 
module name and routine name; this indicates that the val- 
ues refer to procedure calls internal to the runtime library.) 


VAX-11 COBOL 

VAX-11 COBOL is a high-performance implementation of 
COBOL. It is based on American National Standard Pro- 
gramming Language COBOL, X3.23-1974, the industry 
wide accepted standard for COBOL. Most features 
planned for the next COBOL standard, based on the speci- 
fications in the Draft Proposed Revised X3.23 American 
National Standard Programming Language COBOL, are 
also included. 


VAX-11 COBOL also supports an embedded Data Mani- 
pulation Language (DML) interface to VAX-11 DBMS, 
DIGITAL’s CODASYL- compliant Database Management 
System. Additionally, the COPY FROM DICTIONARY 
statement, a DIGITAL extension to COBOL, is a feature 
that allows access to common record definitions stored in 
the VAX-11 Common Data Dictionary. These two facilities 
provide access to the VAX-11 Information Architecture 
from COBOL. VAX-11 COBOL’s support of features in the 
next ANSI COBOL standard, of the VAX-11 Information Ar- 
chitecture, and of other DIGITAL-defined extensions to 
COBOL makes possible a wider range of COBOL applica- 
tions on the VAX-11. 


The next ANSI COBOL standard calls for greater struc- 
tured programming facilities. These facilities include the 
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0001 l=1 


0002 CONTINUE 

0003 J=2 

0004 CONTINUE 

0005 K=3 

0006 CALL SUB1 

0007 CONTINUE 

0008 END 

0001 SUBROUTINE SUB1 

0002 l=1 

0003 J=2 

0004 CALL SUB2 

0005 END 

0001 SUBROUTINE SUB2 

0002 COMPLEX W 

0003 COMPLEX Z 

0004 DATAW/(0.,0.)/ 

0005 Z = LOG(W) 

0006 END 

%MTH-F-INVARGMAT, invalid argument to math library 
user PC 00000449 


%TRACE-F-TRACEBACK, symbolic stack dump follows 


modulename  routinename line relative PC absolute PC 
0000074C #£0000074C 
0000081C 0000081C 
Figure 7-3 


FORTRAN Symbolic Traceback 


EVALUATE statement, scope-delimited statements, and 
the inline PERFORM statement. These structured pro- 
gramming facilities simplify program organization, thereby 
yielding more understandable, reliable, and maintainable 
programs. VAX-11 COBOL supports these structured pro- 
gramming facilities. 


VAX-11 COBOL includes many features that make the 
programmer more productive by simplifying program de- 
velopment and by giving direct access to more VAX/VMS 
facilities. VAX-11 COBOL supports the complete Report 
Writer facility, so reports can be tailored to a particular ap- 
plication without having to make extensive use of the CO- 
BOL I/O verbs and Procedure Division logic for report 
generation. The COBOL SORT and MERGE verbs are sup- 
ported by VAX-11 COBOL, so sorting and merging opera- 
tions can be performed at the source language level. The 
conditional compilation facility supported by VAX-11 CO- 
BOL enables the programmer to specify a compile-time 
qualifier to indicate the particular source lines of aCOBOL 
program to be included in the compilation. This facility al- 
lows the programmer to tailor the program to a particular 
application without having to rewrite the program. 


VAX-11 COBOL also fully supports the contained pro- 
grams facility, commonly referred to as “block structured” 
COBOL. This facility allows the nesting of COBOL pro- 
grams within a containing COBOL program and permits 
the containing program to call a contained program. By 


extending the CALL statement with the BY DESCRIPTOR 
and BY VALUE argument-passing mechanisms, VAX-11 
COBOL provides full access to the VAX/VMS System Ser- 
vice Routines and the VAX-11 Common Runtime Library. 
VAX-11 COBOL supports symbolic characters so that the 
programmer can define nonprintable characters simply, to 
generate video display forms. 


VAX-11 COBOL is properly defined as an implementation 
of ANSI COBOL with full support of the following: 

Full Level 2 Nucleus Module. 

Full Level 2 Table-Handling Module. 

Full Level 2 Sequential I/O Module. 

Full Level 2 Relative |1/O Module. 

Full Level 2 Indexed I/O Module. 

Full Level 1 Report Writer Module. 

Full Level 2 Segmentation Module. 

Full Level 2 SORT/MERGE Module. 

Full Level 2 Library Module. 

Full Level 2 Interprogram Communication Module. 


Besides the VAX-11 object module, the compiler can pro- 
duce a source listing with embedded diagnostics; a ma- 
chine-language listing; a cross-reference listing; and maps 
of filenames, datanames, procedure names, external 
program names, and subschema maps. The cross-refer- 
ence listing and maps can be produced either in al- 
phabetic order or by order of declaration. 


General Characteristics 

Most code in the object module produced by the VAX-11 
COBOL compiler is implemented with inline VAX-11 in- 
structions. The object code takes advantage of such native 
mode features as: 

e Many of the VAX-11 string-manipulation instructions. 

e The packed-decimal instructions. 

e Direct calls to VAX/VMS. 

e Direct calls to VAX-11 RMS. 

e Direct calls to VAX-11 DBMS. 

e Direct calls to VAX-11 SORT. 

e Direct calls to the Common Runtime Library. 

e Transparent access to DECnet. 


The object code produced by VAX-11 COBOL uses the 
VAX/VMS traceback facility for determining the source of 
runtime errors. If a fatal error occurs at runtime, an English 
error message is printed to identify the cause of the error. 
Additionally, the traceback pinpoints the source of the er- 
ror to a specific line number in the COBOL source module 
producing the error. The English error message coupled 
with the traceback facility give the user a powerful debug- 
ging tool for identifying fatal execution errors. 


The VAX-11 Symbolic Debugger can be used for program 
development with VAX-11 COBOL. Features supported in- 
clude the source-program display facility in which the 
COBOL source code is displayed as the debugger traces 
the program. This reduces the need for source listings 
during program development. Other features include 
complete support of COBOL-qualified names and break- 
points and the examination and setting of program vari- 
ables. 
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Object modules produced by the compiler can be linked 
with native-mode object modules produced by other VAX- 
11 language processors including BASIC, FORTRAN, 
PL/I, and MACRO. 


Structured Programming 

Structured programming adds some of the features of 
traditional languages (such as ALGOL and PL/I) to the 
VAX-11 COBOL compiler. This facility makes programs 
easier to develop, understand, and maintain, thereby re- 
ducing program development and maintenance costs. The 
structured programming facilities supported by VAX-11 
COBOL include the EVALUATE statement, scope-delim- 
ited statements, and the inline PERFORM statement. 


The EVALUATE statement, a CASE-like statement found 
in modern programming languages, allows the selection of 
statements to be executed, depending on the state of pro- 
gram variables. Scope-delimited statements simplify CO- 
BOL coding that previously required additional GO TO 
statements and procedure names. The inline PERFORM 
statement reduces program complexity by putting the 
logic of the PERFORM inline. 


In Figure 7-4, a program example from a transaction proc- 
essing application illustrates the usage of the structured 
programming facilities in VAX-11 COBOL. 


The example illustrates the usage of the inline PERFORM 
statement whose scope is delimited by END-PERFORM. 
The inline PERFORM loop initializes monthly transaction 
counts in preparation for the subsequent transaction ana- 
lysis. The EVALUATE statement performs the transaction 
analysis and illustrates the typical usage of this statement: 
a set of actions to be executed, depending on the state of a 
program variable (e.g., TRANSACTION-TYPE). For the 
cases not specifically mentioned, the (catch-all) WHEN 
OTHERS imperative statement sequence is executed that, 
in this example, does exception reporting and a count of 
the transaction errors. The scope delimiters are END-PER- 
FORM, END-READ, END-IF, and END-EVALUATE. These 
help organize the program and help make the program 
more understandable and maintainable. 


Data Types 

VAX-11 COBOL supports the data types specified in the 
ANSI COBOL Standard. VAX-11 COBOL also supports as 
extensions the packed-decimal (COMP-3), floating-point 
(COMP-1), double-floating (COMP-2), and address 
(POINTER) data types. 


The packed-decimal data type (two decimal digits per 

byte) offers the following advantages: 

e Disk storage savings. 

e Faster arithmetic operations than standard numeric-dis- 
play data type. 

e Compatibility with and migration from other COBOL 
vendors. 


Floating-point and double-floating are supported for scien- 
tific applications that also require the facilities of a com- 
mercial language processor like VAX-11 COBOL. The 
POINTER data type, a DIGITAL expansion to COBOL, is 
supported for a COBOL program that calls the VAX/VMS 
Service Routines. 


INITIALIZE STATE. 


PERFORM VARYING | FROM 1 BY 1 UNITI> 12 

MOVE 0TOMONTHLY-RETRIEVE-TRANSAC- 
TIONS (I) 
| MOVE 0 TO MONTHLY-UPDATE-TRANSAC- 
TIONS (I) 

END-PERFORM 
TRANSACTION-LOOP. 


MOVE MONTH-INDEX TO I. 
EVALUATE TRANSACTION-TYPE 
WHEN “RETRIEVE” 
WHEN “retrieve” 
READ TRANS-FILE AT END 
MOVE “EOF” TO TRANS-EOF-SWITCH 
END-READ 
IF TRANS-EOF-SWITCH NOT = “EOF” 
THEN 
ADD 1 TO MONTHLY-RETRIEVE-TRANS- 
ACTIONS (I) 
END-IF 
WHEN “UPDATE” 
WHEN “update” 
REWRITE TRANS-REC 
ADD 1 TO MONTHLY-UPDATE- 
TRANSACTION(1) 
WHEN OTHER 
DISPLAY TRANSACTION-TYPE “is an in- 
valid transaction” 
ADD 1 TO TRANS-ERROR-CNT 
END-EVALUATE. 
GO TO TRANSACTION-LOOP. 


Figure 7-4 
Structured Programming Facilities in VAX-11 COBOL 


VAX-11 COBOL supports the following data types: 
Numeric DISPLAY Data 

Trailing overpunch sign 

Leading overpunch sign 

Trailing separate sign 

Leading separate sign 

Unsigned 

Numeric-edited 

Numeric COMPUTATIONAL Data 

Word fixed binary 

Longword fixed binary 

Quadword fixed binary 

Packed-Decimal Data (COMPUTATIONAL-3) 
Unsigned packed decimal 

Signed packed decimal 
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e Floating-Point Data 

F floating (COMPUTATIONAL-1) 
D_ floating (COMPUTATIONAL-2) 
e Alphanumeric DISPLAY Data 
Alphanumeric 

Alphabetic 

Alphanumeric-edited 

e Address Data 

Pointer 


Contained Programs and CALL Facilities 

VAX-11 COBOL supports both the contained programs 
and CALL-statement facilities. Contained programs allow 
the nesting of one or more contained subprograms in a 
containing program within a source module. A containing 
program can call any of its directly contained subpro- 
grams. Moreover, resources such as variables, files, al- 
phabets, symbolic characters, and use procedures de- 
fined in a containing program can be referenced in the 
contained subprogram, provided such resources are de- 
fined in the containing program with the GLOBAL attrib- 
ute, Thus, the contained-programs facility allows the shar- 
ing of programs and date within the same source module. 


The CALL statement enables a COBOL programmer to 
execute routines that are external or internal to (contained 
in) the source module in which the CALL statement 
appears. The VAX-11 COBOL compiler produces an ob- 
ject module from a source module. The object module file 
can be linked with other VAX-11 object modules to pro- 
duce an executable image. Thus, COBOL programs can 
call external routines written in other VAX-11 languages in- 
cluding BASIC, FORTRAN, PL/I, and MACRO. 


The CALL statement has been extended by allowing argu- 
ments to be passed BY REFERENCE (the default in CO- 
BOL), BY CONTENT, BY DESCRIPTOR, and BY VALUE. 
The BY REFERENCE AND BY CONTENT argument-pass- 
ing mechanisms are defined by the next ANSI COBOL 
standard. The BY DESCRIPTOR and BY VALUE argu- 
ment-passing mechanisms, which are DIGITAL extensions 
to COBOL, are useful in calling the VAX/VMS System Ser- 
vice Routines and the Common Runtime Procedure Li- 
brary. These argument-passing mechanisms conform to 
the VAX-11 Procedure Calling Standard. Also, a COBOL 
program can receive a returned status value from the rou- 
tine it calls via the GIVING clause associated with the ex- 
tended CALL statement. 


Other extensions to VAX-11 COBOL that are useful in ac- 
cessing the VAX/VMS environment from COBOL are the 
external constants (VALUE IS EXTERNAL), address data, 
and the SUCCESS/FAILURE class conditions. 


The external constants facility gives the COBOL 
programmer access to values that are known at linktime 
only. The address data extensions to VAX-11 COBOL in- 
clude: 

e USAGE IS POINTER clause. 

e VALUE IS REFERENCE clause. 


e SET TO REFERENCE statement. 


USAGE IS POINTER specifies that the associated variable 
is to contain an address value; the VALUE IS REFERENCE 
clause allows compile-time initialization of a pointer vari- 
able to the address of COBOL data, and the SET TO 
REFERENCE statement allows runtime initialization of a 
pointer variable to the address of COBOL data. The SUC- 
CESS/FAILURE class condition allows a COBOL program 
to test the low-order bit of a returned status variable froma 
System Service Routine call. 


COBOL Data Manipulation Language (DML) 

VAX-11 COBOL supports the COBOL Data Manipulation 
Language interface to VAX-11 DBMS, DIGITAL’s CO- 
DASYL-compliant Database Management System. 
DIGITAL refers to the DML interface as an “embedded 
DML” because no preprocessor techniques are used by 
the compiler in the translation of the DML statements. In- 
stead, the VAX-11 COBOL compiler translates directly the 
DML statements to calls on the Database Control System 
(DBCS) component of VAX-11 DBMS. 


This DML facility, which is an integral part of the VAX-11 
Information Architecture, consists of the following: 

e The DB statement in the Subschema Section. 

@ The USE FOR DB-EXCEPTION declarative. 

e The database special registers. 

e The data manipulation verbs. 


The DB statement specifies the subschema and schema 

that a DML program uses. The subschema and schema 

define the sets, record types, and realms that the DML 

program manipulates. The USE FOR DB-EXCEPTION de- 

claratives specify error-handling procedures for database 

exception conditions that can arise during DML program 

execution. The database special register DB-CONDITION 

identifies specific database exception conditions. The data 

manipulation verbs enable a DML program to navigate 

through a database; to test the state of a database; and to 

create, update, and delete records in a database. Some of 

the DML verbs supported area: 

@ READY - Begin database transaction. 

e FIND - Find record in database. 

@ GET - Get current record in database. 

e STORE - Store record in database. 

e MODIFY - Update record in database. 

e ERASE - Erase record in database. 

@ COMMIT - Terminate database transaction; change da- 
tabase. 

e ROLLBACK - Terminate database transaction; no 
change to database. 


This program is a COBOL subprogram designed to find 
and return information from the TRANSCHEMA database 
to the caller of the subprogram. The DB statement shows 
that the TRANSUBSCHEMA subschema is to be used for 
the TRANSCHEMA schema (database). The schema is 
given a lookup key — RET-KEY — as input to locate the 
record in the database with the FIND statement. The GET 
statement retrieves the record into memory and returns 
the associated information (via RET-INFO) to the caller. 


Figure 7-5, a program example from a database transac- 
tion processing application illustrates the usage of the 
DML facilities in VAX-11 COBOL. 


IDENTIFICATION DIVISION. 
PROGRAM-ID. | DMLRETRIEVE. 
DATA DIVISION. 
SUB-SCHEMA SECTION. 
DB TRANSUBSCHEMA WITHIN TRANSCHEMA. 
LINKAGE SECTION. 
01 RET-KEY PIC X(7). 
01 RT-INFO PIC X(73). 
PROCEDURE DIVISION USING RET-KEY, RET-INFO GIV- 
ING DB-CONDITION. 
DECLARATIVES. 
RETRIEVAL-HANDLER-SECT SECTION. 
USE FOR DB-EXCEPTION. 
RETRIEVAL-HANDLER. 
ROLLBACK. 
EXIT PROGRAM. 
END DECLARATIVES. 
RETRIEVAL-SECTION SECTION. 
RETRIEVE-REC. 
READY CONCURRENT RETRIEVAL. 
MOVE RET-KEY TO TRANSKEY. 
FIND FIRST TRANSREC USING TRANSKEY. 
GET TRANSREC. 
MOVE TRANSINFO TO RET-INFO. 
ROLLBACK. 
EXIT PROGRAM. 


Figure 7-5 
DML Facilities in VAX-11 COBOL 


The USE FOR DB-EXCEPTION procedure handles any da- 
tabase exception conditions that can arise during the exe- 
cution of the READY, FIND, or GET statements. If this exe- 
cution procedure is invoked due to such an error 
condition, the specific database exception condition, 
which is specified in the special register DB-CONDITION, 
is returned to the caller (via the GIVING option) of the sub- 
program. The ROLLBACK statement terminates the data- 
base transaction and leaves the database unchanged. 


Files and Records 

VAX-11 COBOL Sequential I/O, Relative I/O, and Indexed 
1/0 modules meet the full ANSI Level 2 standard. The lan- 
guage’s Level 2 Indexed I/O madule statements enable 
VAX-11 COBOL programs to use the VAX-11 RMS multi- 
key indexed record management services to process files. 
These files can be accessed sequentially, randomly, or dy- 
namically, using one or more indexed keys to select re- 
cords. VAX-11 COBOL has full variable-length record 
capability for all three |/O modules. 


VAX-11 COBOL supports the EXTERNAL files capability 
for all three I/O modules. This facility allows a program to 
open a file in one separately compiled program and per- 
form record operations in another separately compiled 
program. 


VAX-11 COBOL has extended COBOL by supporting the 
special registers RMS-STS, RMS-STV, and RMS-FILE- 
NAME. These special registers give the COBOL program 
access to the VAX-11 RMS status return values and file 
specification for each I/O operation executed. These spe- 
cial registers are defined in addition to the file status val- 
ues specified in the ANSI COBOL standard. 


An additional extension to VAX-11 COBOL are the file 
sharing and record-locking facilities. These facilities are 
defined for interactive applications where multiple concur- 
rent access to a file is required. The facilities include ex- 
clusive concurrent read-only and concurrent read/write 
access to a file. Automatic and manual record-locking ca- 
pabilities are supported to protect multiple accessors to 
the same record in a file. 


Report Writer Facility 

VAX-11 COBOL supports the full Report Writer Module. 
The Report Writer is a facility that places its emphasis on 
the organization, format, and contents of an output report. 
Although a report can be produced with the standard CO- 
BOL I/O verbs, the Report Writer facility is a much more 
concise facility for report structuring and generation. 
Much of the Procedure Division coding required to pro- 
duce reports in the traditional manner is done automati- 
cally by the VAX-11 COBOL Report Writer Control System. 
Based on the report group description entries in the CO- 
BOL program, the Report Writer Control System 
automatically: 

e Moves data. 

e Constructs print lines. 

e Counts lines on a page. 

e Numbers pages. 

e Produces heading and footing lines. 

e Recognizes the end of logical data subdivisions. 

e Updates sum counters. 


Hence, the VAX-11 Report Writer improves programmer 
productivity and produces programs that are more cost- 
effective to maintain. 


SORT/MERGE Facility 

The VAX-11 COBOL SORT/MERGE module meets the full 
ANSI standard and permits performing sort and merge 
operations at the COBOL source-language level, without 
requiring the programmer to understand the VAX-11 
SORT interface. The COBOL SORT/MERGE capability in- 
cludes sorting and/or merging one or more files in the 
same source module, specifying one or more sort/merge 
key (in ascending or descending order) for each file, and 
the option to use either standard or user-specified in- 
put/output procedures. The VAX-11 COBOL 
SORT/MERGE facility supports the sorting/merging of 
variable-length records and input/output files of differing 
file organizations. 


Source Library Facility 

VAX-11 COBOL supports the full ANS! COBOL Library fa- 
cility. All frequently used data descriptions and program 
text sections can be stored in library files that are available 
to all programs. These files can then be copied into source 
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programs performing textual substitution (i.e., replace- 
ment) in the process. This capability reduces program 
preparation time and eliminates source or error during 
program development. 


VAX-11 COBOL has extended the COPY statement by 
supporting the COPY FROM DICTIONARY statement. This 
facility allows common record defintions to be copied from 
the VAX-11 Common Data Dictionary. This facility is an in- 
tegral part of the VAX-11 Information Architecture. Record 
definitions can be inserted into the dictionary by VAX-11 
DATATRIEVE or by the Common Data Definition Lan- 
guage utility. 


Debugging COBOL Programs 

The VAX-11 compiler produces source-language listings 
with embedded diagnostics indicating line and position of 
error. Fully descriptive diagnostic messages are listed at 
the point of error. Many error conditions are checked at 
compile time, varying from simple informational indica- 
tions to severe error detections. At the user’s option, the 
compiler can also produce a machine-language listings; a 
map of filenames, data names, procedure names, external 
program names, and subschema information; and a 
cross-reference listing. The maps and cross-reference 
listing can be shown in alphabetic order or in order of de- 
claration. The cross reference line numbers, on which 
data-names/procedure-names are defined and indicated, 
are distinguished from read-only references. 


When a fatal error occurs at runtime, an error message 
identifying the cause of the error is displayed to the user. 
Additionally, the system traceback facility prints the se- 
quence of routine invocations active at the time of the fatal 
error. For each routine invocation, traceback displays the 
module name, routine name, and source-line number in 
which either an invocation to another user routine occurs 
or the fatal error itself occurs. 


The VAX-11 Symbolic Debugger can be used for program 
development with VAX-11 COBOL. Features supported in- 
clude the source-program display facility. By using this fa- 
cility, the COBOL source code can be displayed at break- 
points and tracepoints. This reduces the need for source 
listings during program development. Other significant 
features include full support of COBOL-qualified names 
and breakpoints and examination and setting of program 
variables. 


VAX-11 COBOL also supports the ANSI conditional com- 
pilation facility: debug lines. This facility allows “D-lines” to 
be included conditionally in the compilation, depending on 
the presence of the WITH DEBUGGING MODE clause in 
the SOURCE-COMPUTER paragraph. This feature, how- 
ever, requires editing and recompilation of the source pro- 
gram. To overcome this limitation, VAX-11 COBOL has ex- 
tended the conditional compilation facility by providing a 
compile-time qualifier — /CONDITIONALS — to indicate 
the inclusion or omission of debug lines in the compilation. 


VAX-11 COBOL-74 Translator Utility 

The VAX-11 COBOL-74 Translator Utility is helpful to 
those users migrating from PDP-11 COBOL and VAX-11 
COBOL-74 to the VAX-11 COBOL compiler. This utility 
produces a translated source program and a listing with 
flags indicating those language elements that could not be 


mechanically translated and that, therefore, require fur- 
ther investigation by the programmer. 


Some of the differences between VAX-11 COBOL and 

PDP-11 GOBOL or VAX-11 COBOL-74 that require sucha 

translator are: 

® Different allocation and alignment techniques. 

® Different methods of specifying file optimization attrib- 
utes. 


© Different methods of handling variable-length records. 


Fortunately, most differences are transparent to the pro- 
grammer, and moving programs form PDP-11 COBOL or 
VAX-11 COBOL requires little (in some cases, no) pro- 
grammer work. 


Source Program Formats 

The VAX-11 COBOL compiler accepts source programs 
that are coded using either the ANSI standard format or a 
shorter, easy-to-enter DIGITAL terminal format. Terminal 
format is designed for use with the DIGITAL interactive text 
editors. It eliminates the line number and identification 
fields and allows the user to enter horizontal tab charac- 
ters and short text lines. 


The REFORMAT utility reads COBOL source programs 
that are coded using DIGITAL terminal format and con- 
verts the source statements to the ANSI standard format 
accepted by other COBOL compilers throughout the in- 
dustry. It also has the inverse option to accept programs 
written in ANSI standard format and to convert the source 
statements to DIGITAL terminal format. This offers the ad- 
vantages of saving disk space and compile-time 
processing when programs are initially migrating from a 
non-DIGITAL COBOL system to VAX-11 COBOL. 


Additional Features 

Some additional features of the VAX-11 COBOL compiler: 

® Subscripts can be arithmetic expressions. 

e Subscripting and indexing are interchangeable. 

e The CONTINUE statement is included. It transfers con- 
trol to the next executable statement and can replace 
conditional or imperative statements. 

® The AUTHOR, INSTALLATION, DATE-WRITTEN, DATE- 
COMPILED, and SECURITY paragraphs are included. 

© The INITIAL and COMMON clauses on the Program-ID 
are included. 

e User-defined alphabets are included. 

e Alter statement is included. 

e CALL data name is included. Both on OVERFLOW and 
EXCEPTION are supported. 

e CANCEL statement is fully implemented. 

@ INITIALIZE statement is fully implemented. 

® Complete string-handling facilities of COBOL are sup- 
ported including the INSPECT, STRING, and UNSTRING 
statements. The reference-modification (substringing) 
feature is fully supported. 

e SET statement supporting mnemonic names, condition 
names, and the DIGITAL-defined extension of SET TO 
SUCCESS/FAILURE is included. 


© Independent segments (segments 50 and above) of the 
Segmentation module are included. 

® WRITE advancing mnemonic name and associated Spe- 
cial-Names C01 are included. 

® Use of source file libraries by the COPY statement is 

supported. 

The DIGITAL extension of nonnumeric literals as argu- 

ments in the BY REFERENCE, BY CONTENT, and BY 

DESCRIPTOR argument-passing mechanisms is in- 

cluded. 

® Single-quote-limited nonnumeric literals, a DIGITAL ex- 

tension, are supported in addition to the standard dou- 

ble-quote-delimited nonnumeric literals. 

Nonedited MOVE operations are supported. 

© OPEN EXTEND on relative and indexed files is included. 

® ALPHABETIC-UPPER and ALPHABETIC-LOWER class 
conditions are implemented. 

° The ALLOWING extension on the READ, START, 
REWRITE, and WRITE statements for manual locking of 
records in the interactive file sharing environment is in- 
cluded. 

°¢ The READ REGARDLESS extension that allows the 
reading of records in a file-sharing environment — inde- 
pendent of record locks held on the record — is sup- 
ported. 

® The UNLOCK statement, a DIGITAL extension, for expli- 
cit unlocking of records in the file sharing environment is 
implemented. 

® ACCEPT AT END, a DIGITAL extension, is included. 

© Thirty-one character usernames are supported. 


This powerful, flexible, and easy-to-use compiler is 
layered with the VAX/VMS Operating System and is avail- 
able to those customers who require COBOL with 
VAX/VMS V3.0. 


VAX-11 BASIC 

This native-mode BASIC product gives the VAX user all 
the benefits of a highly interactive programming environ- 
ment and high-performance development language. It 
combines the best features of PDP-11 BASIC-PLUS-2 and 
RSTS/E BASIC-PLUS with the significant performance 
and addressing benefits provided by a native-mode VAX 
language that is fully integrated with the VMS environ- 
ment. 


VAX-11 BASIC is a highly extended implementation lan- 
guage. It provides powerful mathematic and string-han- 
dling facilities; support for symbolic characters; and full 
RMS indexed, sequential, and relative I/O operations. 
There does not yet exist an ANSI standard comparable to 
this level of BASIC. 


VAX-11 BASIC can be used as though it were either an in- 
terpreter or a compiler. A fast RUN command and support 
for direct execution of unnumbered statements (immedi- 
ate mode) give the VAX-11 BASIC user the feel of an inter- 
preter. However, this product can also be used in 
compilation mode where it generates native-mode object 
modules like the other VAX compilers. In either case, VAX- 


11 BASIC generates optimized VAX native-mode instruc- 
tions that have extremely fast execution times. Typical 
compilation speeds are up to 3,000 lines per minute, and 
computations will generally execute up to five times faster 
than the same programs would on a PDP-11. 


Following is a brief overview of the general characteristics 
of VAX-11 BASIC. 


General Characteristics 

VAX-11 BASIC generates inline native VAX-11 instructions 

in both its RUN and its compilation modes. The code pro- 

duced takes advantage of VAX/VMS native-mode capabil- 

ities, including: 

e Direct calls on operating system service routines, even 
in immediate mode. 

e Transparent access to DECnet. 


e Direct calls to the Common Runtime Library and stan- 
dard system utilities, including VAX-11 SORT/MERGE. 


Direct calls to separately compiled native-mode 
procedures written in any language that utilizes the VAX 
procedure-calling standard. 


Program sizes up to two billion bytes are allowed. 


e All modules are position-independent (PIC) and can be 
run as fully reentrant code. 


The VAX-11 DEBUG facility has full support for VAX-11 
BASIC. 


The code generated by VAX-11 BASIC uses the standard 
VAX/VMS traceback facility for determining the source of 
runtime errors. If a fatal program error should occur, an 
English message is printed identifying the module and line 
number where the error occurred. The English text, the 
traceback, and the integrated BASIC HELP utility provide 
a powerful program-debugging environment. 


Object modules produced by VAX-11 BASIC can be linked 
with native-mode modules produced by other language 


99 Po sete enn nnn n enna nn nnn nnn nnn enn nnn nnn ennn nnn enn- & 
! EMPLOYEE RECORD DEFINITION(S) & 
! & 
LINE 100: THE “GENERAL DEFINITION” & 
! LINE 200: THE “EXPANDED DEFINITION” & 
100 MAP (REC1) STRING EMPLOYEE.RECORD = 36, & 
REAL RATE, & 
INTEGER ENDFLAG 
110 ! 
200 MAP (REC1) STRING LAST.NAME = 20, & 
STRING FIRST.NAME = 12, & 
STRING MID.INITS = 4, & 
REAL FILL, & 
INTEGER FILL & 
210 Elcsteteletetetetetstatettetataioeraeaaneaatetnaeaaimaammaaats ! 
298 ! 
299 
300 FILE.NAME.1$ = “EMPLOYEE.DAT” 
310 | 
320 OPEN FILE.NAME.1$ AS FILE #1,SEQUENTIAL, ACCESS READ, MAP REC1 
330 ! 
400 TOTAL.RATES = 000000.00 
410 ! 
411 ! 
490 [ eeeeeennnnee-- COMPUTE SUM OF RATES IN FILE --------------- 
498 ! 
499 ! 
500 WHILE NOT ENDFLAG 
GET #1 
TOTAL.RATE = TOTAL.RATE + RATE 
| 
NEXT 
510 
511 ! 
590 [0 eeeeeennn------ REPORT CUMULATIVE SUM BELOW --------------- 
591 | 
999 ! 
600 PRINT “TOTAL.RATE: $”;TOTAL.RATE 
610 
611 | 
690 0 ee weeeenen----- REPORT COMPLETED: CLOSE FILE(S)  --------------- 
699 ! 
700 CLOSE #1 
900 ! 
999 END 


Figure 7-6 
Sample Structured Basic Program 
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100 A(l) = A(l) +1 FOR 1=1TO 100 

50 | PRINT SUMMARY.DATA IF OPTION.1 AND REPORT="MONTHLY” 

ae | PRINT FNHOUSE.PAYMENT UNTIL RATE < 123.45 

mt | GET #1 WHILE EMPLOYEE.NUMBER < 76000 

ae | GOSUB 12300 UNLESS  ERROR.FLAG 

soo. PRINT “NORMAL EXIT” IF TOTAL > 1000 UNLESS ERRORS > 0 
Figure 7-7 


Statement Modifiers 


processors including BLISS, COBOL, FORTRAN, PAS- 
CAL, and MACRO. 


Structured Programming 

Structured programming constructs add some of the fea- 
tures of a block-structured language (such as PASCAL) to 
BASIC, to allow complex programs to be written without 
recourse to subroutines or obscure programming tech- 
niques. This makes programs easier to write and maintain. 


Figure 7-6 below illustrates a record defined by a MAP 
statement, successive retrievals by the use of a GET state- 
ment, and iteration controlled by a WHILE...NEXT state- 
ment block. 


The SUBPROGRAM and FUNCTION constructs in VAX-11 
BASIC have structured END and EXIT statements. In addi- 
tion, BASIC allows the use of statement modifiers that 
allow conditional or repetitive execution of the statement 
without requiring the user to construct unnecessary loops 
or blocks. Any nondeclarative statement in VAX-11 BASIC 
can have one or more statement modifier. The BASIC 
statement modifiers include FOR, IF, UNLESS, UNTIL, and 
WHILE constructs. Each of the statements in Figure 7-7 il- 
lustrates the use of a statement modifier: 


Data Types 

VAX-11 BASIC increases the number of data types avail- 
able to the BASIC programmer by allowing the use of 32- 
bit integer and 64-bit floating-point data values. Table 7-3, 
below, describes the data type supported by VAX-11 BA- 
SIC. 


Declarations 

VAX-11 BASIC allows implicit declaration of variables. Un- 
less specifically named in a declaration statement, a vari- 
able will be declared by its first reference. The PDP-11 
BASIC-PLUS-2 convention is to implicitly type a variable 
or value by the trailing character in its representation, for 
example, ABC$ is a STRING variable; XYZ% and 123% are 
INTEGER; T12, 314159, and 3.14 are implicitly REAL. 


Variables can be declared in COMMON, MAP, or DE- 
CLARE statements. Both COMMON and MAP statements 
are used to declare static storage areas — typically I/O re- 
cords or shared-data blocks. If a program has several 
named common statements with the same name, the com- 
mon program sections (PSECTs) are stored one after the 
other. If several MAP statements have the same name, 
they overlay the same PSECT. 
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Table 7-3 
Data Types 


Data Type 
REAL 


Meaning 


Specifies that the variable or constant 
contains floating-point data. The preci- 
sion depends on the COMPILE com- 
mand qualifier you use. COM- 
PILE/SINGLE specifies 32-bit floating- 
point numbers; COMPILE/DOUBLE 
specifies 64-bit floating-point numbers. 


WORD Specifies that the variable or constant 
contains word-length integer data, re- 
gardless of the COMPILE command 


qualifier you use. 


LONG Specifies that the variable or constant 
contains longword integer data, regard- 
less of the COMPILE command qualifier 


you use. 


INTEGER Specifies that the variable or constant 
contains integer data. This data type de- 
faults to the qualifier used at compile- 
time. If you compile the program with the 
/WORD qualifier, integers are 16 bits 
long; with the /LONG qualifier, 32 bits 


long. 


STRING Specifies that the variable or array con- 


tains string data. 


The DECLARE statement is used to explicitly type vari- 
ables, functions, and constants. Note that the appearance 
of a variable name in a DECLARE statement implies that 
that variable will not be in static storage (see MAP and 
COMMON above). 


Finally, the EXTERNAL statement is provided to let the BA- 
SIC programmer explicitly declare data types for symbols 
external to the current program unit — for example, the 
name of a VMS system service module, an external BASIC 
function, or an external constant that is to be global in an 
application. 


Figure 7-8 illustrates the use of COMMON, MAP, DE- 
CLARE, and EXTERNAL statements. 


100 ! ---------------------- COMMON STATEMENTS _ -------------------- 

101 ! 

102 COMMON (DATASET1) REAL A,B,C,D,E,F,G,H,O,P,Q,R,5,T,U,V,W,X,Y,Z, & 
INTEGER 1,J,K,L,M,N & 
STRING $1,$2,53,S4 

103! 

104 COMMON (DATASET1) LAST.NAME$= 10, FIRST.NAME$=5 

105 ! 

200 ! ----------------------- MAP STATEMENTS _ --------------------- 

201 ! 

202 MAP (DATASET2) REAL PART.NUMBER, COST, & 
INTEGER VENDOR.CODE, QA.INDEX, & 
STRING VENDOR.ID=40 

203! 

204 MAP (DATASET2) REAL FILL, FILL, & 
INTEGER FILL, FILL, & 
STRING VENDOR.NAME = 10, FILL, & 

VENDOR.TWX = 30 

205 ! 

300 ! ------------------------- DECLARE STATEMENTS _------------------------ 

301 ! 

302 DECLARE INTEGER COUNTER.1, COUNTER.2, & 
REAL STANDARD.DEVIATION, & 
LONG A.32.BIT.VARIABLE, & 
WORD A.16.BIT.VARIABLE, & 
STRING LAB.NAME = 20 & 

303 ! 

304 DECLARE INTEGER CONSTANT DEBUG.MODE = 0, & 

MY.P = 3, & 

REAL CONSTANT MY.PI = 3.1416, & 
STRING FUNCTION CONCAT 

305 ! 

306 DEF CONCAT( STRING Y, STRING Z) 

307 CONCAT=Y+Z 

308 FNEND 

309 ! 

310 PRINT CONCAT(“THIS IS”, THE RESULT”) 

311 ! 

312 !----------------------------- EXTERNAL STATEMENTS _ -------------------------- 

401 ! 

402 ! CAN BE USED FOR VMS SERVICES 

404 EXTERNAL INTEGER FUNCTION SYSS$ASSIGN 

405 ! 

406 EXTERNAL INTEGER FUNCTION SYS$TRNLOG ! LOGICAL TRANSLATIONS 

407 ! 

408 EXTERNAL INTEGER FUNCTION SYSS$QIOW ! SYNCHRONOUS QIO CALL 

410 ! 

S00  |---- 2-22-22 nnn nnn enn nnn nn nnn nnn nnn nn enn nn nnn nnn n nnn n nn 


Figure 7-8 
Declaration Statements 


Files and Records 

VAX-11 BASIC supports RMS sequential, indexed, and re- 
lative file organization. In addition, BASIC applications can 
access virtual arrays (stored on files), terminal-format 
files, and block I/O files via RMS. 


The OPEN statement in VAX-11 BASIC allows specifica- 
tion of file organization, access modes, file sharing, record 
formats, record size, and file allocation. At the record level, 
a BASIC program can FIND, GET, PUT, UPDATE, DELETE, 
or RESTORE any record in a file — either sequentially or 
randomly. 


VAX-11 BASIC can access files created by other native- 
mode languages, assuming appropriate data representa- 
tions are maintained with the records. 


Symbolic Characters 

BASIC now supports references to symbolic charac- 
ters—those characters in the 96-character ASCII set that 
do not print — for example, NUL, SOH, FF, CR, etc. Figure 
7-9 illustrates the use of symbolic characters in a BASIC 
program. 


CALL Facility 

The CALL statement allows the BASIC programmer to in- 
voke procedures and functions that are external to the cur- 
rent source module. By using the VMS native-mode LINK 
utility, procedures written in any of the VAX native-mode 
languages can be invoked, that is, BASIC routines can call 
or be called by procedures written in COBOL, CORAL, 
FORTRAN, PASCAL, etc. 


10 PRINT “PROGRAM STARTS...”;LF;LF;“AT ”+TIMES$(0) 
11! 
15 TITLE$ = “SUMMARY REPORT” 
19 ! 
20 PRINT TITLE$;CR; FORI=1TO5 ! Bold copy 
by overprinting 
21 ! 
30 PRINT 
31 ! 
40 PRINT A(l) FOR! = 1TO 10 ! Output report data 
41 ! 
50 PRINT 
51! 
99 END 
Ready 
RUN 
TEST5 28-MAY-1980 17:20 
PROGRAM STARTS... 
AT 05:20 PM 

SUMMARY REPORT 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 
Ready 

Figure 7-9 


Symbolic Characters 


The CALL statement in VAX-11 BASIC has been extended 
to allow a procedure to pass parameters BY REFerence, 
BY VALUE, or BY DESCriptor. These mechanisms, which 
conform to the VAX-11 procedure-calling standard, allow 
BASIC programs to call VMS service routines and accept 
returning status values. 


Sharable Programs 

Applications written in VAX-11 BASIC can be made shara- 
ble images by the VMS LINKER. BASIC now generates 
fully reentrant PIC code. 


Developing BASIC Programs 

VAX-11 BASIC delivers a high-productivity development 

environment. The key features of this environment include: 

e Automatic line number generation via SEQUENCE com- 
mand. 

e Integral line editing with EDIT. 

e A RUN command that allows a program to be placed 
directly into execution without requiring a separate LINK 
operation. 

e Direct execution of unnumbered BASIC statements, al- 
lowing quick verification of algorithms, inspec- 
tion/change of data values, and invocation of subrou- 
tines or functions in a halted BASIC program. 

eAn_ integral HELP facility helps program 
debug/development by providing online reference text 
from the BASIC manual set. 

e The VAX-11 BASIC system can produce source-lan- 
guage listings with embedded diagnostics indicating the 


line and position of any errors. Fully descriptive diag- 
nostic messages are provided at the point of an error. 
Many error conditions are caught at compile time. At the 
user's option, VAX-11 BASIC can also output a ma- 
chine-language listing and/or a cross-reference listing. 


e The VAX/VMS SYMBOLIC DEBUGGER lets the 
programmer set breakpoints and inspect or change the 
value of variables during execution of a program. 


Figure 7-10 illustrates the use of several of these features. 
The text appearing in blue type in Figure 7-10 corresponds 
to user input; the remaining text is supplied by the BASIC 
system. 


The LOAD Command 

A major goal of VAX-11 BASIC is to support a program- 
development environment. The LOAD command allows a 
user to stay in BASIC, even when a program under devel- 
opment involves several separately compiled BASIC sub- 
routines. When a RUN command is issued, any BASIC 
modules moved into memory by the previous LOAD com- 
mand are automatically bound together with the module 
under development, and the resulting in-memory image 
begins execution — that is the user is not required to leave 
BASIC, invoke the LINKER, and use the DCL $RUN com- 
mand. This speeds program development considerably. 


Once an application has been checked out, a final call on 
the LINKER can be used to create a sharable native-mode- 
executable image for production use. 


Error Handling 

VAX-11 BASIC allows user-directed error and event han- 
dling. Occurrence of an error can activate one or more 
routine that handles the error (or event) and then return 
control to the point where the error occurred (RESUME), 
to the calling program (ON ERROR GOBACK), or to the 
BASIC system itself for standard cleanup and return of 
control at the BASIC command level. 


In determining the cause of an error, the BASIC program 
can use the value of ERR — the error message number as- 
signed by BASIC, ERL — the line number where the error 
occured, ERN$ — the name of the BASIC module where 
the error occurred, and ERT$(ERR) — the error message 
text that the BASIC system would print if the error had not 
been trapped by the program. 


Migration to VAX/VMS 

Since the VAX-11 BASIC Field Test, numerous sites 
moved programs from PDP-11 BASIC-PLUS-2 and 
RSTS/E BASIC-PLUS to the native-mode VAX-11 BASIC. 
Many sites have converted applications involving hun- 
dreds of programs and generally have few difficulties. Mi- 
nor changes were made to BASIC-PLUS-2 programs; the 
error checking in VAX-11 BASIC caught actual bugs in 
many “working” programs. BASIC-PLUS programs were 
converted to EXTEND mode (or run through the BASIC- 
PLUS to VAX-11 BASIC translator) and then modified as 
though they were in BASIC-PLUS-2. Typically, these 
changes were made: 


100 ~—s‘'!-------------------- INPUT A FILE NAME, COUNT NUMBER OF LINES IN IT----------------- 
110 LINPUT “What file to be opened ” ,FILE.NAME$ 
140 F.NAMES$ = EDIT$(FILE.NAME$,32%) 
160 OPEN F.NAME$ FOR INPUT AS FILE #1 
180 ON ERROR GOTO 900 
200 LINPUT #1%,TEXT$ FOR |! = 1 to 1000000 
210 STOP 
900 LINE. = ERL 
NUMBER. = ERR 
MESSAGE$ = ERT$(NUMBER.) 
RESUME LINE 910 
910 PRINT “*END, FROM LINE”;LINE.;“WITH TEXT: ”";MESSAGES$; 
PRINT “- AFTER ”;1;“RECORDS” 
991 STOP 
995 PRINT “*** THE END ***” 
999 END 


Ready 
RUNNH 
%BASIC-E-SYNERR, syntax error 


at line 900 statement 4 
RESUME LINE 910 
t 


Ready 
HELP RESUME 
RESUME 


The RESUME statement marks the end of an error handling routine, 
and returns program control to a specified line number. 


Format 

RESUME [<lin-num>] 
Examples 

990 RESUME 300 

or 

990 RESUME 


Ready 


LIST 900 
TEST6 28-MAY-1980 17:15 


900 = LINE. = ERL 
NUMBER. = ERR 
MESSGE$ = ERT$(NUMBER.) 
RESUME LINE 910 


Ready 
EDIT 900 / LINE // 


900 ~=LINE. = ERL 
NUMBER. = ERR 
MESSAGE$ = ERT$(NUMBER) 
RESUME 910 

Ready 


RUN 

TEST6 28-MAY-1980 17:16 

What file to be opened ? TEST6.BAS 

*END, FROM LINE 200 WITH TEXT: ?End of file on device - AFTER 17 RECORDS 
%BAS-I-STO, Stop 

-BAS-I-FROLINMOD, from line 991 in module TEST 6 

Ready 


PRINT MESSAGE$;" FROM FILE”; F.NAME$ 
?End of file on device FROM FILETEST6.BAS 
Ready 


PRINT F.NAME$;CR; FORI=1TO5 
TEST6.BAS 
Ready 


Figure 7-10 
BASIC Program Development Features 
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e the MODE expression on an OPEN statement was 
changed to the corresponding set of keywords, e.g., 
OPEN F$ AS FILE #1 MODE2% 
becomes 
OPEN F$ AS FILE #1, ACCESS APPEND 


e MAP and DIM statements were moved to occur before 
OPEN statements. 


e RSTS/E SYS-CALLS were examined and removed, if 
not supported by VMS. 


Files were then copied over on tape or by using DECnet, 
and the programs were RUN under VAX-11 BASIC. In the 
event errors were detected by BASIC, the online HELP fa- 
cility was used to determine any additional changes 
needed for correct compilation. 


Certain features were carried forward from PDP-11 BA- 
SIC-PLUS and PDP-11 BASIC-PLUS-2 to VAX-11 BASIC 
in order to make the move to VAX easier. These include: 


e BASIC-PLUS to VAX-11 BASIC Translator utility 


Program RESEQUENCE utility from BASIC-PLUS-2 
V1.6 


FIELD statement 

CVT, SWAP, and MAGTAPE functions 
Foreign buffer support 

String arithmetic 

Numerous nonprivileged RSTS/E SYS calls 
Virtual arrays 


The key steps to moving programs and data between BA- 

SIC implementations are: 

e Referring to the BASIC Transportability Manual for 
technical information. 


e Referring to Appendix G of the VAX-77 Users Guide for 
the differences between BASIC-PLUS-2 and VAX-11 
BASIC. 


PRIMES 29-MAY-1980 21:08 

90 OPEN “T.1” FOR OUTPUT AS FILE #1, RECORDSIZE 
132 

100 rem Interface Age’s benchmark program to 

110 rem discover the first 1000 prime numbers 

120 rem 


125 PRINT CHR$(7) 
130 t1 = time(1) 
140 FOR n = 1 to 1000 


150 FOR k = 2TO 500 

160 m=n/k 

170 l=int(m) 

180 IF |= 0 THEN 230 
190 IF | = 1 THEN 220 
200 IF m >1 THEN 220 
210 IF m = 1 THEN 240 
220 next k 


230 PRINT #1, N; 

240 NEXT n 

250 t2 = time(1) 

255 PRINT CHR$(7) 

260 PRINT “Elapsed time: ”;0.1*(t2—t1);“ seconds” 
270 END 


@ Running the translator utility when moving from BASIC- 
PLUS or BASIC-11 to BASIC-PLUS-2 or VAX-11 BASIC. 


Performance 

The programs in Figure 7-11 illustrate the level of com- 
pute-bound performance possible under VAX-11 BASIC. 
Program A was taken from page 130 of the June, 1980, is- 
sue of Interface Age. Program B is very similar and is from 
page 84 of the March, 1980 issue of BYTE magazine. 


Finally, initial performance tests on VAX-11 BASIC were 
samples of the “Towers of Hanoi” program and the Whet- 
stone benchmark. These tests show VAX BASIC execution 
speeds comparable to nonoptimized VAX-11 FORTRAN. 


Additional Functions 

The features listed below demonstrate that BASIC leads 
the competition in virtually every area. This is not an ex- 
haustive list, but does serve to indicate key capabilities of 
this new product. 

e Powerful string-manipulation functions for creating, 
converting, searching, editing, and extracting character 
values. 

Variable names up to 30 characters long. 

Maximum length of a single string is 65,535 characters. 
Multiple statements on a line. 

Multiline IF... THEN...ELSE statements. 


Optional use of line continuator “&” and statement se- 
parator “\’, for example. 


100 PRINT VS. 100 = PRINT & 
PRINT \ PRINT & 
PRINT \ PRINT 


e DCL pass-through in the BASIC command mode by 
simply prefixing the DCL command line with a dollar- 
sign, e.g., 


System CPU Run-time 
TRS-80 Z80 1982 sec 
Technico TI9900 585 sec 
DEC-10 PDP-10 65 sec 
BASIC-PLUS-2 PDP-11/70 11 sec 
VAX-11 BASIC 11/780 2./ sec 


Figure 7-11A 
Program A 


PRIMES 
10 


29-MAY-1980 21:09 
PRIME NUMBER PROGRAM #83 OF 3 


! FROM MARCH 1980 BYTE MAGAZINE 

! PAGE 84 

! “TRS-80 PERFORMANCE... 

EVALUATION BY PROGRAM TIMING 

! (INCLUDES 370/148 PL/I AND BAL TIMES 
| 


Qo Ro Po Qo Lo Ro Lo 


15. DECLARE INTEGER M,K 

20 OPEN “PRIMES3.TMP” FOR OUTPUT AS FILE #1 
30 PRINT “PRIME3 ”+TIME$(0) 

40 PRINT 

45  T1=TIME(1) 

50 —_—~ PRINT #1, 1:23; 


55 C=0 

70 M=3 

80 M=M+2 

90 FOR K = 3 TO M/2 STEP K-1 

100 IF INT(M/K)*K—M = 0 THEN 190 
110 NEXTK 

121. PRINT #1%,M; 

122 C=C+1 


190 IF M < 10000 then 80 
195 PRINT #1%, “C=";C 
196 PRINT “C=";C 
199 T2= TIME(1%) 
P$ = “DONE: "+NUM1$(0.1*(T2—T1))+“ CPU SEC” 
200 PRINT P$ 


TRS-80 BASIC 280 23470 sec 
Assembler 280 1370 sec 
Optimizing 370/148 79 sec 
PL/I 

BAL 370/148 56 sec 
VAX-11 BASIC 11/780 58.2 sec 


PRINT #1, PS 
201 END 
Figure 7-11B 
Program B 
Ready Program control flow 
$DIR *.BAS, *.OBJ 


® Provision for up to ten individual BASIC object library 
files for automatic use at RUNtime when developing an 
application using separately compiled BASIC subrou- 
tines. 


VAX-11 C 


VAX-11 C fully supports all of the language features of C, 
as described in The C Programming Language, by Kerni- 
ghan and Ritchie*. The program flow control constructs for 
logical and efficient program structuring and the rich as- 
sortment of operators that enable an elegant conciseness 
of expression are incorporated in VAX-11 C. So, too, are 
the common runtime routines — only those UNIX-specific 
routines that cannot be reasonably emulated under 
VAX/VMS are omitted. VAX-11 C even includes language 
extentions developed since the Kernighan and Ritchie 
book was published, including the structure assignment 
feature. 


VAX-11 C is more than just a faithful implemention of the C 
programming language. It is a very powerful implementa- 
tion with an impressive collection of features and, just as 
important, VAX-11 C is an integrated VAX/VMS layered 
language product; this means that programmers have 
available to them all of the services and program develop- 
ment aids that the VAX/VMS system provides. 


The C Language 

VAX-11 C is a versatile programming language that com- 
bines many of the features of a high-level language with 
the generality of MACRO. 


7-20 


VAX-11 C uses simple English for performing conditional 
loops (WHILE, FOR, DO), simple decisions (IF — ELSE), 
and multicase decisions (SWITCH) and for escaping loops 
or multicase decisions (BREAK, GOTO label:). These facil- 
ities not only aid in creating well-structured programs, but, 
combined with C’s clear statement and expression delimi- 
ters, they can provide source code that is easy to under- 
stand and maintain. 


Operators 


VAX-11 C provides an unusually large array of operators 
that allow programming with clarity and economy of 
expression. 


Data types 

VAX-11 C was designed to be a powerful generalist among 
languages. It uses only the fundamental datatypes com- 
monly represented by computers directly, including integ- 
ers of various and fixed sizes, and single-precision and 
double-precision floating point. VAX-11 C also provides 
for user-defined or enumerated scalars (ENUM values). 
ENUM datatypes are defined by writing the type name fol- 
lowed by an ordered list of indentifiers that are the con- 
stants of that type. 


Runtime support 

In order to retain its flexibility of application, the C lan- 
guage does not directly support many of the functions 
usually attributed to high-level languages — for example, 
I/O or common math routines. But most implemenations 
of C include a common set of runtime support routines for 


accomplishing those tasks. VAX-11 C includes all of the 
non-UNIX-specific runtime support offered in the Bell La- 
boratories version (even many of the UNIX-specific rou- 
tines have been emulated) and all of the additional support 
included in the VAX-11 Common Runtime Library. 


Unique to VAX-11 C — New keywords for sharing data 
among program modules are offered by VAX-11 C to aug- 
ment the capability of the standard keywork for passing 
arguments, EXTERN. The new keywords — GLOBALDEF, 
GLOBALREF, and GLOBALVALUE, which allow VAX-11 C 
programs to define and reference global symbols, offer an 
alternative method for dealing with external variables and 
values. They provide, in addition to enhanced datasharing 
among C program modules, a convenient and efficient 
way for a C function to communicate with MACRO pro- 
grams, with VAX/VMS system services and data struc- 
tures, and with other high-level languages that support 
global symbol definition, such as VAX-11 PL/I. 


The Compiler 

VAX-11 C has an extremely powerful compiler that gener- 
ates sharable, position-independent, native VAX object 
code directly from C source programs (i.e., no separate 
assembly step) at an average rate in excess of 3,000 
source statements per minute. In the process, the com- 
piler can perform global and local optimization by, for ex- 
ample, doing global flow analysis, assigning automatic 
variables to register temporaries, and removing invariant 
computations from loops, to mention a few. The compiler 
also does peephole optimizations on the generated ma- 
chine code. The result is that VAX-11 C produces faster 
and smaller programs. 


The VAX-11 C compiler will produce an annotated listing 
with statement numbers and, optionally, an inline listing of 
generated machine code, expanded macros, storage allo- 
cation map, cross-reference listing of variable usage, and 
compilation statistics. 


The VAX/VMS Programming Environment 

What most distinguishes VAX-11 C from other implemen- 
tations of the language is that it is an integrated constituent 
of a total VAX/VMS environment. This means VAX-11 C 
provides programmers with an easy interface and an ex- 
ceptional array of services and tools that can maximize 
their productivity and the efficacy of the programs they 
produce. 


VAX-11 RMS 

In addition to performing stream file access, which is con- 
ventional among most C implementations, and because it 
is a VAX/VMS layered language product, VAX-11 C allows 
all of the features of the VAX-11 Record Management Ser- 
vices (RMS) to be exploited. RMS supports sequential, re- 
lative, and indexed file organizations, thus expanding the 
potential applications for C programs. 


VAX/VMS System Services 

The VAX-11 C programmer can utilize all of the VAX/VMS 
System Services, including, for example, the ability to 
define logical names. By referencing files or devices with 
logical names that are defined by the user prior to execu- 
tion, VAX-11 C programs can be device- or file-indepen- 
dent — a useful feature for many applications. 
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The common language environment 

All DIGITAL VAX-11 language products, VAX-11 C among 
them, follow the VAX calling standard. This permits C pro- 
grammers to call, as subroutines, object modules created 
using other languages — say VAX-11 FORTRAN or VAX- 
11 PL/I — so that particular tasks can be coded in the 
most suitable language and proven routines already in use 
can be applied by the programmer without having to rein- 
vent the wheel. Of course the inverse is true as well; pro- 
grams written in other VAX-11 languages can call routines 
originally developed in VAX-11 C. 

VAX-11 Symbolic Debugger — 

With the VAX-11 Symbolic Debugger, the VAX-11 C pro- 
grammer can set breakpoints and examine and modify the 
contents of user variables dynamically while the C 
program is executing. Additionally, if a C program is not 
performing as expected, program execution can be inter- 
rupted, the debugger called, and execution continued. 


Compatibility Across Implementations 

There are no national or international standards for the C 
language; however, The C Programming Language is gen- 
erally regarded as the definitive document, along with 
technical notices subsequently published by the American 
Telephone and Telegraph Company. But, because C is a 
relatively simple language, even without formal stan- 
dardization, most programs written in VAX-11 C can be re- 
compiled successfully using another implementation of 
the language, or vice versa, usually with few if any modifi- 
cations. 


Certain incompatibilities among implementations do exist, 
however, especially in machine-specific library routines. 
To aid creating portable programs, VAX-11 C provides 
predefined constants (“vms,” “vax,” and “vaxtic”) that 
can be used, for example, in program-control lines to de- 
cide whether to compile source code that might not be 
portable. The VAX-11 C compiler command, CC, also has 
an optional feature that detects several nonportable pro- 
gram constructions and issues warning messages. 


UNIX/VAX, VAX/VMS Coexistence 

The C programming language was originally developed at 
Bell Laboratories for creating the UNIX operating system; 
it has become the language of choice for many applica- 
tions developed on that system. As an aid to migrating 
programs from UNIX systems to VAX/VMS, the VAX-11 C 
runtime library includes many of the UNIX-specific UNIX/C 
routines, emulated to run under VMS. Also, VAX-11 C al- 
lows UNIX-style stream I/O access to VAX-11 record for- 
mats. 


Table 7-4 

Summary of C Operators 
Operator Example Result 
— [unary] —a negative ofa 
* [unary] *a reference to object at address a 
& [unary] &a address ofa 
~ ~wa one’s complement ofa 
++ [prefix] ++a a after increment 
++ [postfix] a++ a before increment 
—-— [prefix] --a a after decrement 
—-— [postfix] a-— a before decrement 


Table 7-4 (Cont.) 


Operator Example Result 
sizeof sizeof(t1) size in bytes of type t1 
sizeof e size in bytes of expression e 


(type-name) (ti)e expression e, converted to type t1 


+ a+b a plus b 

— [binary] a-b aminus b 

* [binary] a*b a times b 

/ a/b a divided by b 

% a%b remainder of a/b 

>> a>>b a, right-shifted b bits 
<< a<<b a, left-shifted b bits 

< a<b 1 if a <b; 0 otherwise 
> a>b 1ifa> b; 0 otherwise 
<= a<=b 1 ifa <= b; 0 otherwise 
>= a>=b 1 if a >= b; 0 otherwise 


a== 1 if a equal to b; 0 otherwise 
!= al=b 1 if a not equal to b; 0 otherwise 


&[binary] a&b bitwise AND of a and b 


ait b bitwise OR of aand b 

+ atb bitwise XOR (exclusive OR) of a and b 
&& a&&b logical AND of a and b (yields 0 or 1) 
tt atib logical OR of a and b (yields 0 or 1) 

! la logical NOT of a (yields 0 or 1) 

? a?e1:e2 expression e1 if ais nonzero, 


expression e2 if ais zero 


* “The C Programming Language,” B. Kernighan and D. Ritchie, 
Prentice-Hall, 1978. 


VAX-11 PASCAL 

VAX-11 Pascal, a reentrant native-mode compiler, is an 
extended implementation of the Pascal language as de- 
fined by Jensen and Wirth in the Pascal User Manual and 
Report (1974). 

Pascal has become an increasingly popular general pur- 
pose language. It implements a well-chosen, compact set 
of general purpose language features. In addition, porta- 
bility is easily achievable in programs written in Pascal. 
Block structuring and flexible data types make Pascal a 
good language for commercial users. It is also suitable for 
systems programming and research applications. 

VAX-11 Pascal takes advantage of the VAX-11 hardware 
floating-point character-instruction sets and the virtual 
memory capabilities of the VAX/VMS operating system. 
Features common to other languages of VAX/VMS are 
also available through VAX-11 Pascal, including: 


e VAX-11 Symbolic Debugger support. 

e Separate compilation of modules. 

e Standard call interface to routines written in other lan- 
guages. 

e Access to VAX/VMS system services. 


At compile time, options available to the process include: 
e Runtime checks for illegal assignment to set variables 
and subrange variables and illegal array subscripts. 
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e Cross-reference listing of identifiers. 
e Source program listing. 
e Machine-code listing. 


Though VAX-11 Pascal has access to the Common Run- 
time Library routines of VAX/VMS, it also has Pascal-spe- 
cific Runtime Library routines installed in STARLET.OLB. 
Such routines primarily provide I/O interfaces to the Re- 
cord Management Services (RMS). 


Standard Pascal provides a modular, systematic approach 
to computerized problem solving. Major features of the 
language are: 


e INTEGER, REAL, CHAR, BOOLEAN, user-defined, and 
subrange scalar data types. 


ARRAY, RECORD, SET, and FILE structured data types. 
Constant identifier definition. 

FOR, REPEAT, and WHILE loop control statements. 
CASE and IF-THEN-ELSE conditional statements. 
BEGIN...END compound statement. 

GOTO statement. 


GET, PUT, READ, WRITE, READLN, and WRITELN I/O 
procedures. 


e Standard functions and procedures. 


In addition, VAX-11 Pascal incorporates the following ex- 
tensions to standard Pascal, some of which are common in 
other Pascal implementations: 


@ Lexical. e Predefined functions. 


- | Uppercase and lowercase letters treated identically, - LOWER (a,n) 
except in character and string constants. - SNGL(d) 

- |New reserved words: MODULE, OTHERWISE, SE- - UPPER (a,n) 
QUENTIAL, VALUE, %DESCR, %IMMED, “%IN- - EXPO (r) 
CLUDE, and %STDESCR. 

a - CARD (s) 

- |The exponentiation operator, **. CLOCK 


- Hexadecimal and octal constants. 
- DOUBLE constants. 
- $and_characters in identifiers. 


- UNDEFINED (r) 
e Extensions to procedures READ and WRITE. 

- READ (or READLN) of user-defined scalar type. 
e Predefined data types. - READ (or READLN) of string. 


- DOUBLE - WRITE (or WRITELN) of user-defined scalar type. 

- SINGLE - WRITE (or WRITELN) of any data using 
e Predefined procedures. hexadecimal or octal format. 

- CLOSE (f) e %INCLUDE directive. 

- FIND (f,n) e VALUE initialization. 

- OPEN (f,...) @ OTHERWISE clause in CASE statement. 

- DATE (a) e External procedure and function declarations. 

- HALT e Dynamic array parameters. 

-  LINELIMIT (f,n) e Extended parameter specifications. 

- TIME (a) - %DESCR 


EXAMPLE 23-MAY-1980 
MACHINE-CODE 


GENERATED CODE 


23:00:05 VAX-11 PASCAL VERSION V1.1-29 PAGE 2 


(PRIOR TO BRANCH OPTIMIZATION) 


LINE ADDRESS OPCODE OPERANDS BYTESTREAM (HEXADECIMAL; READ FROM RIGHT TO LEFT) 
0002 MOVAB *VAR(O, 0),R11 58 00 00 00 00 00 9E 
0009 MOVL R13,*VAR(O, 4) 00 00 00 00 00 5D DO 
0010 CLRL —(R14) 7ED4 
0012 CLRD —(R14) 7E7C 
0014 PUSHAL (R11)Bt8 08 AB DF 
0017 CALLS #1,PAS$INPUT 00 00 00 00 00 01 FB 
001E PUSHAL (R11)Bt8 98 AB DF 
0021 PUSHAL (R11)Wt236 00 EC CB DF 
0025 CALLS #2,PAS$OUTPUT (22) 00 00 00 00 00 02 FB 
@8 002C MOVL R14,(R13)Bt—12 F4 AD 5E DO 
9 0030 MOVAB (R11)Wt236,R10 5A 00 EC CB9E 
0035 SUBL2 #16,R14 (5) 5E 10 C2 
0038 (2) = PUSHL R10 5A DD 
003A MOVAB *VAR(2, 0),R9 59 00 00 00 00 00 9E 
0041 MOVL R9,(R14)Bt4 04 AE 59 DO 
0045 MOVL #21,(R14)Bt12 OC AE 15 DO 
0049 MOVL #21,(R14)Bt8 08 AE 15 DO 
004D CALLS #5,PAS$WRITESTR 00 00 00 00 00 05 FB 
0054 MOVAB (R11)Wt236,R10 5A 00 EC CB9E 
EXAMPLE 23-MAY-1980 23:00:05 VAX-11 PASCAL VERSION V1.1-29 PAGE 4 
CROSS_REFERENCE 
CROSSREFERENCE LISTING 
A @ 4 11 12 @ 
B (2s) 4 11 12 (26) 
C 4 12 13 
INPUT 1 10 
OUTPUT 1 
GLOBALLY DEFINED IDENTIFIERS: 
EOLN 0 10 
FALSE 0 14 
READLN 0 11 
REAL 0 4 @) 
SQR 0 12 12 
WRITELN 0 9 13 17 


Figure 7-12 
Sample VAX-11 Pascal Code 
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@) 
EXAMPLE 23-MAY-1980 23:00:05 
01 11-OCT-1979 11:34:47 
LINE LEVEL 
NUMBERS PROC STMT STATEMENT 
100 #1 1 
200 2 1 
300-3 1 label 10; 
@) 400 © 4 1 @) var A,B,C:REAL; 
500 5 1 
600 6 1 begin 
700 7 1 
800 8 0 repeat 
900 9 2 
1000 10 (0) 2 
1100 11 2 READLN(A,B); 
1200 12 


%PAS-W-DIAGN 


1300 13 2 

1400 14 2 until FALSE; 

1500 15 1 

1600 16 1 10: 

1700 17 1 WRITELN(’ Done’; 


°7PAS-F-DIAGN 
() ***ERROR  4:“)” expected 
*“** ERROR 20: “,” expected 
1 


1800 18 
1900 19 1 end. 
20 0 


Compilation time = 1.35 seconds ( 


1 Nonstandard feature 


17. (9) 


2 Errors 


Last error(warning) on line 
Active options at end of compilation: 


VAX-11 PASCAL VERSION V1.1-29 
_DB1:[200,200]JEXAMPLE.PAS;4 (1) 


C := (SQR(A) + SQR(B)) ** 0.5; 
450 


2 
*** WARNING 450: nonstandard Pascal: Exponentiation 
WRITELN('Hypotenuse is: ’,C); 


@) © 


PAGE 1 


©) 


program EXAMPLE(INPUT,OUTPUT); 


WRITELN('Enter triangle sides’); 
if EOLN(INPUT) then goto 10; 


©) ® & 
420,*,4 “17 ==> = 12 
@) 


889 lines/minute). 


NODEBUG,STANDARD,LIST,NOCHECK,WARNINGS,CROSS_ REFERENCE, ©) 


MACHINE-CODE,OBJECT,ERROR_LIMIT = 30 


Figure 7-12 (Cont.) 


- %IMMED 
- %IMMED PROCEDURE and %IMMED FUNCTION 
- %STDESCR 


e Separate compilation of procedures and functions. A 
separate compilation unit is termed a MODULE, and 
several routines can be part of a MODULE. Each MOD- 
ULE is eventually embedded in a host or main program. 


The OPEN, CLOSE, and FIND procedures extend the I/O 
capabilities of the VAX-11 Pascal language. The OPEN 
procedure can contain file attributes that define the crea- 
tion or subsequent processing of the file. A FIND pro- 
cedure is another extension to the language for direct ac- 
cess to sequential files of fixed-length records. The 
standard I/O procedures of GET, PUT, READ, WRITE, 
READLN, and WRITELN are also available in VAX-11 Pas- 
cal. 


The extended parameter specifications %DESCR, % 
IMMED, and %STDESCR are added to the Pascal lan- 
guage to denote the method of argument passing when 
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calling a system service, procedure, or a function not writ- 
ten in VAX-11 Pascal (for example, in VAX-11 FORTRAN 
or MACRO). 


Sample VAX-11 Pascal Code 

Figure 7-12 illustrates a VAX-11 Pascal program that a 
user can write to calculate the hypotenuse of a right trian- 
gle. The inputs to the program are the length of the two 
sides of the triangle and the output is the length of the hy- 
potenuse. This version of the program has not yet been 
debugged to illustrate how error messages are reported. 


Compiler Listing Format 

Figure 7-12 contains the compiler listing of the hypotenuse 

program. The compiler listing contains the following three 

sections: 

e Source-code listing — When the LIST qualifier is speci- 
fied, the source code is listed by default. 


e Machine code listing — To generate the machine code 
listing, the MACHINE CODE qualifier must be specified. 


® Cross-reference listing — To generate cross references 
for all identifiers used in the program, the 
CROSS _ REFERENCE qualifier must be specified. 


The following sections describe the format of the user- 
requested listings. Note that the numbers in these sections 
are keyed to the circled numbers in the listings of Figure 7- 
12. 


Title Line — Each page of the listing contains a title line. 
The title line lists the module name (1), the date and time of 
the compilation (2), the Pascal compiler name and version 
number (3), and the listing page number (4). 


Source-Code Listing 

Each page of the source-code listing contains a line under 
the title line specifying the date and time of source-file 
creation (5) and the VAX/VMS file specification of the 
source file (6). 


Source-Code Listing — The lines of the source code are 

printed in the source-code listing. In addition, the listing 

contains the following information pertaining to the source 
code: 

@ SOS line numbers (7) — If the source lines were created 
or edited in a Pascal module with the SOS editor, SOS 
line numbers appear in the leftmost column of the 
source code listing. SOS line numbers are irrelevant to 
the Pascal compiler. 


Line numbers (8) — The compiler assigns unique line 
numbers to the source lines in a Pascal module. The 
symbolic traceback that is printed if the program en- 
counters an exception at run time refers to these line 
numbers. 


Procedure level (9) — Each line that contains a declara- 
tion lists the procedure level of that declaration. Pro- 
cedure level 1 indicates declarations in the outermost 
block. The procedure level number increases by one for 
each nesting level of functions or procedures. 


® Statement level (10) — The listing specifies a statement 
level for each line of source code after the first BEGIN 
delimiter. The statement level starts at O and increases 
by 1 for each nesting level of Pascal structured state- 
ments. The statement level of a comment is the same 
level as that of the statement that follows it. 


Errors and Warnings — The source-code listing includes 
information on any errors or warnings detected by the 
compiler. A line beneath the source code line in which the 
error is detected specifies whether the diagnostic is a 
warning or an error. In addition, the error description can 
contain the following information: 

e A circumflex (t) that points to the character position in 

the line where the error was detected (11). 


e A numeric code, following the circumflex, that specifies 
the particular error (12). On the following lines of the 
source listing, the compiler prints the text that corre- 
sponds to each numeric code (13). Note that one source 
program error often causes the Pascal compiler to de- 
tect more than one error (14). 


e An asterisk (*) that shows where the compiler resumed 
translation after the error (15). 

e The line number in which the error was detected (16) 
and the line number of the last line containing an error 
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diagnostic (17). These error-line numbers can be used 
to trace the error diagnostics backwards through the 
source listing. 


Summary — At the end of the source listing, the compiler 
lists the amount of time required for the compilation (18). If 
program generated warning or error messages resulted, 
the compiler prints a summary of all the errors (20) and the 
source line number of the last message (19). Finally, the 
compiler lists the status of all the compilation options (21). 


Machine Code Listing 

The machine-code listing (if requested with the MA- 

CHINE CODE qualifier) follows the source listing. The ma- 
chine-code listing contains: 

® Symbolic representation (22) — The symbolic represen- 
tation, similar to a VAX-11 MACRO instruction, appears 
for each object instruction generated. Because the 
Pascal compiler operates in one pass, it must generate 
these instructions before it performs branch optimiza- 
tion. Branch optimization can cause certain BRW in- 
structions to be deleted. Therefore, these instructions 
will not be identical to those appearing in the executable 
image. 

Source-line number (23) — A source-line number marks 
the first object instruction that the compiler generated 
for the first Pascal statement on that source line. 


Hexadecimal address (24) — The hexadecimal address 
is an approximation of the address of the object instruc- 
tion. Do not use these addresses for debugging pur- 
poses because they do not correctly correspond to the 
locations in the executable image. The branch optimiza- 
tion mentioned above can change the addresses of the 
object instructions. 


Hexadecimal instruction (25) — This is the hexadecimal 
representation of the object instruction. The 
hexadecimal instruction should be read from right to left 
because the rightmost byte has the smallest address. 
Again, because of its one-pass operation, the compiler 
must generate some object instructions before it can de- 
termine the address bytes of their operands. The ad- 
dresses of these operands are printed as zeros. After 
generating the hexadecimal representation of an in- 
struction — before writing the object code file — the 
compiler places the correct values into the binary object 
code. 


Cross-Reference Listing 

The cross-reference listing (if requested with the 

CROSS REFERENCE qualifier) appears after the machine 

code listing. It contains two sections: 

e User-specified identifiers (26) — This section lists all the 
user declared identifiers. 


@ Globally defined identifiers (27) — This section lists the 
Pascal predefined identifiers that the program uses. 


Each line of the cross-reference listing contains an identi- 
fier (28) and a list of the source-line numbers wherein the 
identifier is used (29). The first line number indicates 
where the identifier is declared. Predefined identifiers are 
listed as if they were declared on line 0. The cross-refer- 
ence listing does not specify pointer type identifiers that 
are used before they are declared. 


VAX-11 PL/I 

VAX-11 PL/I is an extended implementation of the General 
Purpose Subset (X3.74—"“Subset G”) of ANSI PL/I, X3.53- 
1976. VAX-11 PL/I extensions to the subset language are 
either full-language PL/I features included because they 
were highly desirable or system-specific extensions in- 
tended to provide more complete access to VAX/VMS fea- 
tures. VAX-11 PL/I is a sharable compiler which runs un- 
der the VMS operating system and generates highly 
optimized position-independent machine code. 


All compiler-generated code, with the exception of some 
built-in functions calls and !/O operations, is inline. Out-of- 
line operations are performed by the VAX-11 Common 
Runtime Library. Most high-level language operations are 
supported directly by VAX hardware instructions. 


The VAX Symbolic Debugger fully supports VAX-11 PL/I. 
All VMS system services are available to programs written 
in PL/I via the CALL statement. Furthermore, VAX-11 PL/I 
fully supports RMS — the VAX/VMS record management 
services. A set of ENVIRONMENT options provides access 
to a large subset of RMS features. All RMS file organiza- 
tions are supported: sequential, relative, and indexed. 


VAX-11 PL/I fully supports the VAX interlanguage calling 
standard. Routines written in any other native-mode lan- 
guage can call PL/I and vice versa. For system services, a 
library of predefined ENTRY declarations is provided to 
minimize the coding required to use these services. 


Subset G is a rich language that combines the scientific 
computing abilities of FORTRAN, the commercial data 
handling of COBOL, the string manipulation of BASIC, and 
the block structuring of ALGOL. Selected extensions fur- 
ther enhance these basic capabilities. 


The remainder of this section: 
® Provides an overview of the G Subset. 


® Lists the extension made to the language to provide en- 
hancements for PL/I programs executing in the 
VAX/VMS operating-system environment. 


® Lists features of full PL/I that were excluded from the G 
Subset but that have been incorporated in the im- 
plementation of VAX-11 PL/I. 

® Lists the implementation-defined values that are used in 
VAX-11 PL/I. 


THE G (GENERAL-PURPOSE) SUBSET 

The G subset of PL/I was designed to be useful in scien- 

tific, commercial, and system programming, especially on 

small and medium-size computer systems. Among the pri- 

mary goals of the design of the subset were: 

® To include features that were easy to learn and to use 
and to exclude features that were difficult to learn or 
prone to error. 


© To provide a subset that would be easily portable from 
one computer system to another. 

® To exclude features that were not often used and whose 
implementation greatly increased the complexity of the 
runtime support required by the compiler. 


The essential elements of the subset are described below. 
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Program Structure 
The G subset includes a complete character set with com- 
ments, identifiers, decimal arithmetic constants, and sim- 
ple string constants. 


Begin blocks and DO-groups are included in the subset. 
Each block or group in the program must be terminated 
with an END statement. For example: 


ON ENDFILE(INFILE) BEGIN; 
PUT SKIP LIST(‘End of input file’); 
CLOSE FILE(INFILE); 
END; 


Program Control 

The following program control statements are included in 
the subset: CALL, RETURN, IF, DO, GOTO, null, STOP, 
ON, REVERT, and SIGNAL. 


The DO statement options supported are TO, BY, WHILE, 
and REPEAT. 


An IF statement can contain unlabeled THEN and ELSE 
clauses. A null statement can be used to specify no action 
for a given condition. For example: 


IF A<B THEN; /* no action */ 
ELSE PUT LIST(‘valid’); 


An ON statement can specify a single condition. The con- 
dition names supported are ERROR, ENDFILE, ENDPAGE, 
FIXEDOVERFLOW, KEY, OVERFLOW, UNDEFINEDFILE, 
UNDERFLOW, and ZERODIVIDE. For example, an attempt 
to divide by zero can be detected and handled by an ON- 
unit that specifies ZERODIVIDE: 


ON ZERODIVIDE BEGIN; 
/* action to be taken 


wf 

END; 
Storage Control 
The subset includes the assignment statement and the as- 
signment of array and structure variables whose dimen- 
sions and data types match. The subset also permits ag- 
gregate promotion, that is, the assignment of a scalar 
expression to every element or member of an aggregate 
variable. For example: 


ARRAY = A,; 
evaluates the expression A, and assigns the result to every 
element of ARRAY. 


The subset also provides the INITIAL attribute that speci- 
fies initial values for variables when they are declared. For 
example: 
DECLARE EOF BIT(1) STATIC INITIAL(‘0’B); 

declares an “end of line” flag named EOF and sets its ini- 
tial value to ‘0’B (false). In the subset, only static variables 
can be initialized. 

The ALLOCATE statement with the SET option and the 
FREE statement are included in the subset. ALLOCATE 
dynamically allocates storage for a based variable and 
sets a pointer to the location of the allocated storage. For 
example: 


ALLOCATE LIST ELEMENT SET(LIST POINTER); 


allocates storage for the based variable LIST ELEMENT 
and sets LIST POINTER to the location of the allocated 
storage. The allocated storage can be subsequently re- 
leased by: 


FREE LIST POINTER~LIST ELEMENT 


Input/Output 

The I/O statements are: 

@ OPEN and CLOSE. 

READ, WRITE, DELETE, and REWRITE for record 1/0. 
Record I/O statements operate on an entire record ina 
file. 

GET, and PUT, with FILE, STRING, EDIT, LIST, PAGE, 
SKIP, and LINE options for stream I/O. Stream I/O 
statements operate on a stream of ASCII input or output 
data; the stream can be a file of such data or a charac- 
ter-string variable or expression. 


The file attributes, specified in DECLARE or OPEN, are 
DIRECT, ENVIRONMENT, INPUT, KEYED, OUTPUT, 
PRINT, RECORD, SEQUENTIAL, STREAM, and UPDATE. 
The FORMAT statement is included. The format items are 
E, F, P, A, X, R, PAGE, SKIP, COLUMN, TAB, and LINE. 
Format items and the GET EDIT and PUT EDIT statements 
provide a formatted I/O capability comparable to that of 
FORTRAN. For example: 


PUT EDIT(A) (F(5,2)); 


writes out the value of A as a fixed-point decimal number 
of up to five digits, two of which are fractional. 


Attributes and Pictures 

The DECLARE statement is included in the subset. All 
names must be declared, either by means of a DECLARE 
statement or by means of a label prefix. 


The attributes supported are: ALIGNED, AUTOMATIC, 
BASED, BINARY, BIT, BUILTIN, CHARACTER, DECIMAL, 
DEFINED, DIRECT, ENTRY, ENVIRONMENT, EXTERNAL, 
FILE, FIXED, FLOAT, INITIAL, INPUT, INTERNAL, KEYED, 
LABEL, OPTIONS, OUTPUT, PICTURE, POINTER, PRINT, 
RECORD, RETURNS, SEQUENTIAL, STATIC, STREAM, 
UPDATE, VARIABLE, and VARYING. 


The picture characters included are CR, DB, S, V, Z, 9, —, 
+, $, and *. The picture insertion characters (. , / B) are 
also included. Pictures allow special characters to be in- 
serted in a fixed-point decimal number. The picture facility 
(on output) is comparable to the PRINT USING statement 
of BASIC. For example: 


PUT EDIT(A) (P ‘$99999V.99’); 


Writes out the value of A in fixed-point format with five in- 
tegral digits and two fractional digits, and precedes the 
number with a dollar sign. 


Built-in Functions and Pseudovariables 

PL/I provides a set of built-in functions that perform com- 
mon calculations and data manipulation. A built-in func- 
tion can be used without declaration, wherever an expres- 
sion of the same data type is permitted. The built-in 
functions in the subset are: ABS, ACOS, ADDR, ASIN, 
ATAN, ATAND, ATANH, BINARY, BIT, BOOL, CEIL, 
CHARACTER, COLLATE, COPY, COS, COSD, COSH, 
DATE, DECIMAL, DIMENSION, DIVIDE, EXP, FIXED, 
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FLOAT, FLOOR, HBOUND, INDEX, LBOUND, LENGTH, LI- 
NENO, LOG, LOG2, LOG10, MAX, MIN, MOD, NULL, ON- 
CODE, ONFILE, ONKEY, PAGENO, ROUND, SIGN, SIN, 
SIND, SINH, SQRT, STRING, SUBSTR, TAN, TAND, TANH, 
TIME, TRANSLATE, TRUNC, UNSPEC, VALID, and VER- 
IFY. 


Subset G also provides pseudovariables that can be used 
as the targets of assignment statements. The pseudovari- 
ables are PAGENO, STRING, SUBSTR, and UNSPEC. For 
example, whereas the SUBSTR built-in function returns a 
substring of a specified bit or character string, the 
SUBSTR pseudovariable allows the assignment of an 
expression to such a substring. 


Expressions 

The subset supports all infix and prefix operators, the lo- 
cator qualifier, parenthesized expressions, subscripts, and 
function references. Implicit conversion from one data 
type to another is restricted to those contexts in which the 
conversion is likely to produce the desired results. For ex- 
ample: 


DECLARE | DECIMAL; 

|= ‘1.2’; 
converts the character string ‘1.2’ to the decimal equi- 
valent and assigns it to the decimal variable |. However, 
the following assignment: 


DECLARE B BIT(8); 

B =— ‘A’; 
is not valid because, to be convertible to a bit string, a 
character string must consist entirely of O and 1 charac- 
ters. 


VAX-11 EXTENSIONS TO THE 
G SUBSET STANDARD 


Procedure-Calling and Condition-Handling Extensions 

The following extensions to PL/I were made to allow VAX- 

11 PL/I procedures to call procedures written in any other 

programming language that also supports the VAX-11 

calling standard. 

1. The attributes ANY and VALUE describe how data are 
to be passed to a called procedure. 


2. The VARIABLE option for the ENTRY attribute permits 
a PL/I procedure to call a non-PL/I procedure with an 
argument list of variable length. It also permits a pro- 
cedure to omit arguments in an argument list. 

3. The DESCRIPTOR built-in function can be used to 


pass an argument by descriptor to a non-PL/I pro- 
cedure. 


The following new attributes provide storage classes for 
PL/I variables. These attributes permit PL/I programs to 
take advantage of features of the VAX-11 linker and to 
combine PL/I procedures with other procedures that use 
these storage classes. 

1. The GLOBALDEF and GLOBALREF attributes let you 
define and access external global variables and op- 
tionally to place all external global definitions in the 
same program section. 

The READONLY attribute can be applied to a static 
computational variable whose value does not change. 


3. The VALUE attribute defines a variable that is, in ef- 
fect, a constant whose value is supplied by the linker. 


The following extensions to ON condition handling provide 
support for condition handling in the VAX/VMS environ- 
ment: 

1. The ON statement supports the ANYCONDITION key- 
word. The ON-unit established by this keyword is 
executed when any condition occurs for which no ex- 
plicit ON-unit exists. 


The ON statement supports programmer-named con- 
ditions with the VAXCONDITION keyword. 

The RESIGNAL built-in subroutine permits an ON-unit 
to keep a signal active. 

The ONARGSLIST built-in function provides an ON- 
unit with access to the mechanism and signal argu- 
ments of an exception condition. 


Support of VAX-11 Record Management Services 

The options of the ENVIRONMENT attributes provide sup- 

port for many of the features and control values of the 

VAX-11 Record Management Services (RMS). Additional 

extensions have been made to the PL/I language to aug- 

ment this support, as described below. 

1. The OPTIONS option is supported on the GET, PUT, 
READ, WRITE, REWRITE, and DELETE statements. 
For example: 


GET LIST(A) OPTIONS(PROMPT(‘Enter A>’)); 
displays the prompt “Enter A” on the user's terminal. 


These built-in subroutines provide file-handling and 
control functions: DISPLAY, EXTEND, FLUSH, 
NXTVOL, REWIND, and SPACEBLOCK. 


Miscellaneous Extensions and Deviations 

The following list summarizes miscellaneous extensions 

and deviations. 

1. The RANK and BYTE built-in functions are supported 
and they return the ASCII code for a given character 
and the ASCII character for a given code, respectively. 


The expression in a WHILE clause or in an IF state- 
ment can be a bit string of any length. When evalu- 
ated, the expression results in a true value if any bit of 
the string expression is a one and in a false value if all 
bits in the string expression are zeros. 


The control variable and the expressions in the TO, 
BY, and REPEAT options of the DO statement are not 
restricted to integers and pointers. 


FULL PL/I FEATURES SUPPORTED 

The items listed below are features that are explicitly ex- 

cluded from the subset standard, but that have been im- 

plemented in VAX-11 PL/I. These features all exist in full 

PL/I. 

1. The ENTRY statement is supported and it provides a 
means of defining alternate entry points to a pro- 
cedure. For example, such an alternate entry point 
can be invoked by a function reference even though 
the containing procedure is invoked as a subroutine. 


The ENVIRONMENT option is supported on the 
CLOSE statement. 
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The picture characters Y, T, |, and R are supported, 
and pictures can include iteration factors. These char- 
acters provide an additional means of representing 
zeros in anumber (Y) and allow a digit and a sign to be 
represented by a single character (T, I, R). 

The RETURNS CHARACTER(*) is valid. That is, a 
function can return a character string whose length is 
determined by the program. 

The FINISH condition is supported. 


A REWRITE statement need not specify the FROM op- 
tion if the most recent !/O operation on the file was a 
READ statement with the SET option. (A READ SET 
statement acquires a record from an input file and 
sets a pointer to the location of the I/O buffer contain- 
ing the contents of the record.) 


The AREA and OFFSET attributes are supported. The 
AREA attribute allows declaration and manipulation of 
an entire region of memory (up to 500 million bytes), 
and the OFFSET attribute declares variables that are 
offsets into such an area. Offset variables can be used 
in most contexts in which pointer variables are permit- 
ted. Allocation within an area must be controlled by a 
user-written procedure. 


The OFFSET and POINTER built-in functions are sup- 
ported. These functions convert pointer values to 
offset values, and vice versa. 


The POSITION attribute is supported. POSITION al- 
lows the declaration of a DEFINED variable to specify 
the position within the base string at which the defi- 
nition begins. 

Automatic variables can be initialized. The INITIAL at- 
tribute can contain scalar expressions and asterisks 
with automatic variables. Asterisks indicate that the 
corresponding variable or element in the declaration 
is not assigned an initial value. 

The SET option is optional on the ALLOCATE state- 
ment if the allocated variable was declared with 
BASED (pointer-reference). The ALLOCATE state- 
ment then allocates storage for the based variable and 
sets the referenced pointer variable to the storage lo- 
cation. 

The character pair /* can be embedded in a comment. 
This feature permits a statement such as: 


IF {VALID(P) THEN 
PUT LIST(‘Input error’);/* check validity */ 


10. 


11. 


12. 


to be “commented out”: 


/* IF {VALID(P) THEN 
PUT LIST(‘Input error’);/* check validity */ 


IMPLEMENTATION-DEFINED VALUES 
AND FEATURES 


1. VAX-11 PL/I supports the full 256-character ASCII 
character set. 
2. The default precisions for arithmetic data are: 


FIXED BINARY (31) 
FIXED DECIMAL (7) 


/* Translates logical names to equivalent strings */ 
TRNLN: PROCEDURE OPTIONS (MAIN); 
DECLARE SYS$TRNLOG ENTRY( 


/* VAX/VMS system service */ 


/ Parameters: */ 


CHARACTER(*), 
FIXED BINARY(15), 
CHARACTER(*) 

) 
OPTIONS(VARIABLE) 
RETURNS(FIXED BINARY(31)); 


DECLARE INPUT CHARACTER(63) VARYING, 
OUTPUT CHARACTERS(63), 
OUTPUT _LEN FIXED BINARY(15), 
RETURN STAT FIXED BINARY(31), 
SUCCESS BIT(1) 


/* Logical name */ 
/* Length of translated name */ 
/* Translated name */ 


/* Some arguments optional */ 
/* SYSSTRNLOG returns integer */ 


/* Input name */ 


/* Translated name */ 

/* Length of translated name */ 

/* Return status of SYS$TRNLOG */ 
/* Successful return */ 


ALIGNED BASED (ADD(RETURN_STAT)); 


DECLARE SS$_NOTRAN 
GLOBALREF FIXED BINARY(31) VALUE; 
%REPLACE NOTEND BY ‘1’B; 
ON ENDFILE(SYSIN) STOP; 
DO WHILE (NOTEND): 


PUT SKIP; 
GET LIST(INPUT) 


/* Flag for undefined name */ 


/* “Always true’--to control DO-group */ 


/* Stop on CTRL/Z from terminal */ 


/* Terminated by ON-unit */ 


OPTIONS(PROMPT(‘Enter logical name ’)); 


/*Invoke sytem service as PL/I function reference: */ 
RETURN_STAT = SYS$TRNLOG((INPUT),OUTPUT_LEN,OUTPUT,,,); 


IF RETURN_STAT = SS$_NOTRAN THEN 


PUT SKIP LIST(INPUT::‘not defined’); 
ELSE IF SUCCESS THEN 


PUT SKIP LIST(INPUT::‘is ’:: SUBSTR(OUTPUT,1,OUTPUT_LEN)); 


END; 
END TRNLN; 


Figure 7-13 


Sample VAX-11 PL/I Code 


FLOAT BINARY (24) 
FLOAT DECIMAL (7) 


where each precision is the number of binary or deci- 
mal digits, as appropriate. 

The maximum record size for SEQUENTIAL files is 
32,767 bytes minus the length of any fixed-length con- 
trol area. 

The maximum key size is 255 bytes for character keys. 
The default value for the LINESIZE option is as fol- 
lows. The line size is used by stream I/O statements to 
determine when to go to a newline. 


e If the output is to a physical-record-oriented de- 
vice, such as a lineprinter or terminal, the default 
linesize is the width of the device. 


e If the output is to a print file, the default linesize is 
132. 

@ If the output is to a nonrecord device (magnetic 
tape), the default linesize is 510. 
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The default value for the PAGESIZE option is as 

follows. The pagesize is used by stream output (PUT) 

statements to determine when to signal the ENDPAGE 

condition. 

@ Ifthe logical name SYS$LP_LINES is defined, the 
default pagesize is the numeric value of 
SYS$LP_LINES — 6. 


@ If SYS$LP_LINES is not defined, or if its value is 
less than 30 or greater than 90, or if its value is not 
numeric, the default pagesize is 60. 


The values for TAB positions are columns beginning 
with column 1 and every eight columns thereafter: 1, 
9, 17, 25, .. 8*i+1, where i is (linesize)/8. List-directed 
output (by the PUT LIST statement) is positioned on 
tab stops if the output is to a file with the PRINT attri- 
bute. 


The maximum length allowed for a file title is 128 char- 
acters. File titles are VAX/VMS file specifications that 
are associated with PL/I file constants and file vari- 
ables. 


The maximum number of digits in editing fixed-point 
data is 34. 
The maximum numbers of digits for each combination 
of base and scale are: 

FIXED BINARY —31 

FIXED DECIMAL —31 

FLOAT BINARY —113 

FLOAT DECIMAL —34 
The default precision for integer values is 31. 


The maximum number of arguments that can be 
passed to an entry point is 253. 


10. 


11. 
12. 


VAX-11 PL/I Programming Example 

Figure 7-13 illustrates a VAX-11 PL/I program. This pro- 
gram calls a VAX/VMS system service (SYS$TRNLOG) to 
determine the equivalence string for a logical name. 


The program TRNLN calls a VAX/VMS system service, 
SYS$TRNLOG, to determine the equivalence string for a 
logical name. SYS$TRNLOG is declared as an external en- 
try constant with three parameters: 


1. Acharacter string of any length, representing the logi- 


cal name. 

2. An integer representing the length of the translated 
name. 

3. A character string of any length representing the 


translated name itself. 


The declaration also states that SYS$TRNLOG returns an 
integer and can have an argument list of variable length. 


Note that the explicit declaration of SYS$TRNLOG is 
shown here for clarity. VAX-11 PL/I is supplied with a li- 
brary of predefined entries for VAX/VMS system services, 
so the declaration of SYS$TRNLOG can be replaced by 
the single statement: 


YINCLUDE SYS$TRNLOG; 


The program also uses a global reference to 
SS$_NOTRAN; the return value of the system service 
equals SS$_NOTRAN when there is no defined equi- 
valence for the given logical name. 


SYS$TRNLOG actually requires that its first and third ar- 
guments be the addresses of character-string descriptors. 
VAX-11 PL/I allows you to pass a character string by de- 
scriptor by declaring the corresponding parameter as 
CHARACTER(*). Such a parameter can have an argument 
that is a fixed-length character string of any length. If the 
written argument for such a parameter is a varying-length 
string, a dummy argument is created by the compiler. To 
avoid the accompanying warning message, the argument 
INPUT is enclosed in parentheses. 


When a dummy argument is created, the invoked pro- 
cedure cannot modify the associated parameter. There- 
fore, the translated name (OUTPUT) is not declared as a 
varying-length string. Instead, OUTPUT and OUT- 
PUT LEN both are supplied as arguments to 
SYS$TRNLOG, which then assigns the necessary values to 
them. The translated name is written out with a reference 
to the SUBSTR built-in function: 


SUBSTR(OUTPUT,1,OUTPUT_ LEN); 


that writes out a substring beginning at character 1 of 
OUTPUT and continuing for OUTPUT LEN characters. 
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A sample session with the program might be: 


$ DEF LNK$LIBRARY DB1:[PROJECT]MYLIB,OLB<RET> 
$R TRNLN<RET> 


Enter logical name>LNK$LIBRARY <RET> 
LNK$LIBRARY is DB1:[PROJECT]MYLIB.OLB<RET> 
Enter logical name>GRACE<RET> 

GRACE not defined 

Enter logical name>{Z 


$ 


The VAX-11 BLISS-32 Compiler 

The VAX-11 BLISS-32 compiler performs a number of op- 
timizations. These include common subexpression elimi- 
nation, removal of loop invariants, constant folding, block- 
register allocation, peephole replacement, test instruction 
elimination, jump versus branch instruction resolution, 
branch chaining, and cross-jumping. 


The VAX-11 BLISS-32 compiler optionally produces 
source text and generated code in a format closely resem- 
bling a VAX-11 assembly listing. Other options allow the 
programmer to control the degree of optimization, sup- 
press production of object code, determine types and for- 
mats of output listings, generate traceback information, 
and specify the types of information to be listed at the ter- 
minal. 


BLISS-32 generates sharable, reentrant and position-in- 
dependent code. These features make it easy to use 
BLISS-32 for writing software to be included in sharable li- 
braries for use by any native language. It is also useful for 
writing connect-to-interrupt device handlers and user- 
written system services. 


Library and Require Files 

BLISS-32 provides two methods for including commonly 

used text into BLISS programs at compile time. These in- 

volve use of either library files or require files: 

e Library Files — These special files, which are created by 
the compiler in a previous library compilation, are in- 
voked by the LIBRARY declaration in the BLISS source 
program. 


e Require Files — These are source (text) files that are in- 
voked via the REQUIRE declaration in the BLISS source 
program. 


Because library files are “precompiled,” lexical processing 
and declaration parsing and checking need not be 
repeated each time these files are included in a compila- 
tion; their use results in a considerable reduction in total 
compilation time. 


The contents of require files must be fully processed each 
time the file is used in a compilation. Hence, using require 
files will, in general, be less efficient than using library files. 
However, because these files operate under a less strin- 
gent set of syntactical rules, their use can be warranted in 
situations wherein a higher level of flexibility is desired. 


Macros 

VAX-11 BLISS-32 provides an extensive macro-building 
facility, allowing frequently used groups of declarations or 
expressions to be expressed in an abbreviated way. Ma- 
cros are defined via MACRO declarations and are ac- 


cessed by simple call statements. They are fully expanded 
at compile time. BLISS-32 allows parameters to be speci- 
fied in the macro definition, thus allowing each block of 
text to be specialized by the actual parameters passed to 
it. Macros can be positional or keyword and can be simple, 
iterative, or conditional. 


Debugging 

The VAX-11 BLISS-32 compiler produces a list of error 
messages showing the source program line on which the 
error occurred followed by a description of the error. If the 
error is recoverable, then the compiler will generate a 
“warning” diagnostic and continue with the compilation 
process. If the error is serious enough to invalidate the 
compiler’s internal representation of the module, then an 
“error” diagnostic is generated, and processing ceases 
following the syntax checking; no object module is pro- 
duced. 


If an error occurs at execution time, the process image can 
access the VAX-11 Symbolic Debugger program. This 
program can be accessed when the object module is 
linked with the DEBUG option. The DEBUG program al- 
lows the programmer to examine and deposit values in 
storage, set breakpoints, call routines, trace through a 


0002 BEGIN 
0003 
0004 LIBRARY ’SYSS$LIBRARY:STARLET’; 
0005 
0006 MACRO 

M 0007 
0008 UPLIT BYTE( %REMAINING) %; 
0009 
0010 OWN 
0011 timebuf: 
0012 msgbuf: 
0013 msgdesc: BLOCK[8,BY TE] 
0014 PRESET( 
0015 
0016 
0017 BIND 


VECTOR[2], 


0019 
0020 EXTERNAL ROUTINE 


wae we we we wee wee wee wee le ele tlw hl hl hl hl wh hl hl OhlhlUlh CC Ol hl Ohl Ol Oh Ohl hl Ohl Ol Oh lh Ol Ol ele le lee ee ee ee ee ee ee et we 


desc[] = %CHARCOUNT(%REMAINING), 


VECTOR[80,BYTE], 


[dsc$w_length]= 80, 
[dsc$a_pointer] = msgbuf ); 


program as it executes, and perform other operations use- 
ful in checking out a program. VAX-11 DEBUG under- 
stands BLISS syntax and permits the use of the user’s 
symbolic names. (See the section on the Symbolic Debug- 
ger for a further description of VAX-11 debugging facili- 
ties.) 


Transportability Features 

The BLISS-32 language is designed to facilitate transpor- 
tability, that is, the writing of programs that can be 
executed on architecturally different machines with little or 
no modification. BLISS compilers also exist for the DEC- 
system-10 and DECSYSTEM-20 (BLISS-36), and for the 
PDP-11 (BLISS-16). Several language features enhance 
transportability: 

e The high-level language constructs can be transferred 

from one machine to another with little or no alteration. 


e Machine-specific functions can be separated from the 
common mainline code via modularization, macros, and 
library and require files. 

e Parameterization allows machine-specific characteris- 
tics to be passed to BLISS data structures. 

e The compiler can be instructed to perform transporta- 
bility checking via the “LANGUAGE (COMMON)” mod- 
ule-head switch. 


0001 MODULE showtime( IDENT ='1-1’ %TITLE 'SHOW TIME’, MAIN=timeout)= 


! Defines System Services, etc. 


!A VAX-11 Style String descriptor 


!64 bit system time 
! Output msg. buffer 
! String descriptor 

! for output buffer 


0018 fmtdesc= UPLIT(DESC(’At the tone, the time is’, %“CHAR(7), °115%T’ )); 


0021 lib$put_output: ADDRESSING _MODE(GENERAL); !From VMS RTL 
0022 
0023 ROUTINE timeout= 
0024 BEGIN 
0025 LOCAL 
0026 RSLT: WORD; ! Resultant string length 
0027 
0028 $GETTIM( TIMADR=timebuf ); ! Get time as 64 bit integer 
0029 
P 0030 $FAOL( CTRSTR=fmtdesc, ! Format control-string address 


P 0031 OUTLEN=nsIit, ! Resultant length (only a word!) 

P 0032 OUTBUF=msgdesc, ! Output buffer descriptor address 
0033 PRMLST=%REF(timebuf)); ! Address of pointer to time block 
0034 
0035 MSGDESC[dsc$w_length] = .rsit; ! modify output descriptor 
0036 
0037 lib$put_output( msgdesc ) ! print the formatted time 
0038 
0039 END; 

Figure 7-14 


Sample VAX-11 BLISS-32 Code 


BLISS’s transportability makes it an ideal language for 
system programming applications and a desirable alterna- 
tive to assembly language coding in those applications in 
which extreme machine dependence is not involved. 


BLISS-32 Sample Program 

Figure 7-14 illustrates how VAX-11 BLISS-32 can call 
VAX/VMS system services and the VAX-11 Common Run- 
Time Procedure Library to print the current time on 
SYS$SOUTPUT. 


VAX-11 CORAL 66 

The VAX-11 CORAL 66 compiler compiles in compatibility 
mode and generates native-mode object code under 
VAX/VMS. The CORAL 66 language, derived from JOVIAL 
and ALGOL-60 in 1966, is the standard language pre- 
scribed by the British government for military realtime ap- 
plications and systems implementation. A government 
agency controls the language standard for CORAL 66; this 
language was first widely used in military projects begin- 
ning in 1970. Her Majesty’s Stationery Office publishes the 
Official Definition of CORAL 66. 


The CORAL 66 language replaces assembly-level pro- 
gramming in a number of commercial, process control, re- 
search, and military applications. It is particularly adapted 
to long-life products requiring flexibility and ease of 
maintenance. 


VAX-11 CORAL 66 is a block-structured language. A block 
is a piece of a program that can be entered only at the be- 
ginning. Though internal structures cannot be “seen” from 
the outside, statements inside a block can “see” out. Be- 
cause sorting is possible, programs can be written that in- 
clude information that is accessible for only for the period 
of time it is required, and no longer. In this way, unwanted 
interactions among program parts are avoided, and out- 
of-date information is very quickly forgotten. 


To satisfy realtime needs, CORAL 66 allows different 
modules of the same suite of programs to be executed at 
apparently the same time. A CORAL 66 compiler assumes 
that any subroutine global to the whole program is likely to 
be active at the same time as any other, so the compiler 
assures that such subroutines do not share any local sto- 
rage. Interactions, however, can be explicitly arranged by 
the programmer. A program consists of communicators 
and separately compiled segments. Each segment has the 
form of an ALGOL-60 block, within which blocks and pro- 
cedures can be nested to arbitrary depth. In the absence 
of communicators, block structure would prevent different 
segments from using common data, labels, switches, or 
procedures. The purpose of a communicator is to specify 
and name those objects that are to be commonly accessi- 
ble to all segments. The presence of communicators im- 
poses a modular and disciplined approach to program- 
ming larger systems where a team of programmers is 
employed. 
In addition to the functionalities prescribed in the Official 
Definition, the VAX-11 CORAL 66 compiler provides the 
following features: 

BYTE, LONG (82-bit integer) and DOUBLE (64-bit float- 

ing-point) numeric types. 
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Generation of reentrant code at the procedure level. 
Switch-selectable option to optimize generated code. 
Conditional compilation of defined parts of source code. 


English text error messages at compile and (optionally) 
runtime. 


Switch-selectable option to control listing output. 


INCLUDE keyword to incorporate CORAL 66 source 
code from user-defined files. 


Switch-selectable option to read card format. 


VAX-11 CORAL 66 is essentially a high-level block-struc- 
tured language possessing certain facilities associated 
with low-level languages; it is designed for use on small or 
medium-size dedicated computers. One of the main inten- 
tions is that programs written in CORAL 66 should be fast 
to execute, take up limited quantities of storage, and easy 
to write. 

The realtime applications of the language are implicit 
rather than explicit, permitting the utilization of any hard- 
ware or special features. Procedures, optionally with par- 
ameters, permit communication with and reaction to exter- 
nal events. This is aided further by a direct code facility 
that enables machine code to be included in the source 
program for extra efficiency in any critical tasks. 


VAX-11 MACRO 

The VAX-11 MACRO assembler accepts one or more 
source module written in MACRO assembly language and 
produces a relocatable object module and optional as- 
sembly listing. VAX-11 MACRO is similar to PDP-11 MA- 
CRO, but its instruction mnemonics correspond to the 
VAX native instructions. VAX-11 MACRO is characterized 
by: 

e Relocatable object modules. 


e Global symbols for linking separately assembled object 
programs. 


e Global arithmetic, global assignment operator, global la- 
bel operator and default global declarations. 


User-defined macros with keyword arguments. 
Multiple macro libraries with fast access structure. 
Program sectioning directives. 

Conditional assembly directives. 

Assembly and listing control functions. 
Alphabetized, formatted symbol table listing. 
Default error listing on command output device. 

A Cross-Reference Table (CREF) symbol listing. 


Symbols and Symbol Definitions 

Three types of symbols can be defined for use within 
MACRO source programs: permanent symbols, user-de- 
fined symbols, and macro symbols. Permanent symbols 
consist of the VAX instruction mnemonics and MACRO 
directives and do not have to be defined by the user. User- 
defined symbols are those used as labels or defined by 
direct assignment. Macro symbols are those symbols used 
as macro names. 


MACRO maintains a symbol table for each type of symbol. 
The value of a symbol depends on its use in the program. 
To determine the value of a symbol in the operator field, 


the assembler searches the macro symbol table, user 
symbol table, and permanent symbol table — in that order. 
To determine the value of the symbol used in the operand 
field, the assembler searches the user symbol table and 
the permanent symbol table in that order. The search or- 
ders allow redefinition of permanent symbol-table entries 
as user-defined or macro symbols. 


User-defined symbols are either internal to a source pro- 
gram module or global (externally available). An internal 
symbol definition is limited to the module in which it 
appears. Internal symbols are local definitions which are 
resolved by the assembler. 


A global symbol can be defined in one source program 
module and referenced within another. Global symbols 
are preserved in the object module and are not resolved 
until the object modules are linked into an executable pro- 
gram. With some exceptions, all user-defined symbols are 
internal unless, explicitly defined as being global. 


Directives 

A program statement can contain one of three different 
operators: a macro call, a VAX instruction mnemonic, or 
an assembler directive. MACRO includes directives for: 
Listing control. 

Function specification. 

Data storage. 

Radix and numeric usage declarations. 

Location counter control. 

Program termination. 

Program boundaries information. 

Program sectioning. 

Global symbol definition. 

Conditional assembly. 

Macro definition. 

Macro attributes. 

Macro message control. 

Repeat block definition. 

Macro libraries. 


Listing Control Directives 

Several listing-control directives are provided in MACRO 
to control the content, format, and pagination of all listing 
output generated during assembly. Facilities also exist for 
titling object modules and presenting other identification 
information in the listing output. 


The listing-control options can also be specified at assem- 
bly time through qualifiers in the command string issued to 
the MACRO assembler. The use of these qualifiers pro- 
vides initial listing-control options that can be overridden 
by the corresponding listing-control directives in the 
source program. 


Conditional Assembly Directives 

Conditional assembly directives enable the programmer 
to include or exclude blocks of source code during the as- 
sembly process, based on the evaluation of stated condi- 
tion tests within the body of the program. This capability 
allows several variations of a program to be generated 
from the same source module. 
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The user can define a conditional assembly block of code 
and, within that block, issue subconditional directives. 
Subconditional directives can indicate the conditional or 
unconditional assembly of an alternate or noncontiguous 
body of code within the conditional assembly block. Con- 
ditional assembly directives can be nested. 


Macro Definitions and Repeat Blocks 

In assembly language programming, it is often convenient 
and desirable to generate a recurring coding sequence by 
invoking a single statement within the program. In order to 
do this, the desired coding sequence is first established 
with dummy arguments as a macro definition. Once a 
macro has been defined, a single statement calling the 
macro by name with a list of real arguments (replacing the 
corresponding dummy arguments in the macro definition) 
generates the desired coding sequence or macro expan- 
sion. MACRO automatically creates unique symbols when- 
ever a label is required in an expanded macro, to avoid 
duplicate label specifications. Macros can be nested; that 
is, the definition of one macro can include a call to another. 


An indefinite repeat block is a structure that is similar to a 
macro definition, except that it has only one dummy argu- 
ment. At each expansion of the indefinite repeat range, 
this dummy argument is replaced with successive ele- 
ments of a specified real-argument list. This type of macro 
definition does not require calling the macro by name, as 
is required in the expansion of conventional macros. An 
indefinite repeat block can appear within or outside of 
another macro definition, indefinite repeat block, or repeat 
block. 


Macro Calls and Structured Macro Libraries 

A program can call macros that are not defined in that pro- 
gram. A user can create libraries of macro definitions, and 
MACRO will look up definitions in one or more given li- 
brary file when the calls are encountered in the program. 
Each library file contains an index of the macro definitions 
it contains, to enable MACRO to find definitions quickly. 


Program Sectioning 

The MACRO program-sectioning directives are used to 
declare names for program sections and to establish cer- 
tain program-section attributes. These program-section 
attributes are used when the program is linked into an im- 
age. 

The program-sectioning directive allows the user to ex- 
ercise complete control over the virtual memory allocation 
of a program, since any program attributes established 
through this directive are passed to the linker. For exam- 
ple, if a programmer is writing multiuser programs, the 
program sections containing only instructions can be de- 
clared separately from the sections containing only data. 
Furthermore, these program sections can be declared as 
read-only code, qualifying them for use as protected, 
reentrant programs. 


PDP-11 FORTRAN IV/VAX to RSX 

FORTRAN IV is an extended FORTRAN implementation 
based on American National Standard (ANSI) FORTRAN, 
X3.9-1966. PDP-11 FORTRAN IV code is executed in com- 


patibility mode under VAX/VMS. The FORTRAN IV lan- 
guage includes the following extensions to the ANSI stan- 
dard; 


General expressions allowed in all meaningful contexts. 


e Mixed-mode arithmetic. 

e BYTE data type for character manipulation. 

e ENCODE, DECODE statements. 

e PRINT, TYPE, and ACCEPT input/output statements. 

e Direct-access unformatted input/output DEFINE FILE 
statement. 

e Comments allowed at the end of each source line. 

e PROGRAM statement. 

e OPEN and CLOSE file access control statements. 

e List-directed input/output. 


Additionally, virtual arrays are supported on target sys- 
tems with memory management directives. Virtual arrays 
are memory-resident and require enough main memory to 
contain all elements of all arrays. 


The PDP-11 FORTRAN IV compiler is a fast, one-pass 
compiler. Compiler options allow program size versus ex- 
ecution speed (threaded code versus inline code) trade- 
offs. FORTRAN IV compiler optimizations include: 
Common subexpression elimination. 

Local code tailoring. 

Array vectoring. 

Optional inline code generation for integer and logical 
operations. 


MACRO-11 assembly language subroutines can be called 
from FORTRAN IV programs. FORTRAN IV also includes a 
set of object modules, called the Object Time System 
(OTS), that are selectively linked with compiler-produced 
object modules to produce an executable program. 


MACRO-11 

MACRO-11, the PDP-11 assembly language, is included in 
the compatibility-mode environment. Programs written in 
MACRO-11 can be assembled to produce relocatable ob- 
ject modules and optional assembly listings. MACRO-11 
provides the following features: 

e Relocatable object modules. 

@ Global symbols for linking separately assembled object 
programs. 

Device-name and filename specifications for input and 
output files. 


User-defined macros. 
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Comprehensive system macro library. 
Program sectioning directives. 
Conditional assembly directives. 


Assembly and listing-contro!l functions at program and 
command string levels. 


e Alphabetized, formatted symbol-table listing. 
e Default error listing on command output device. 


Symbols and Symbol Definitions 

Three types of symbols can be defined for use within MA- 
CRO-11 source programs: permanent symbols, user-de- 
fined symbols, and macro symbols. Accordingly, MACRO 
maintains three types of symbol tables: the Permanent 
Symbol Table (PST), the User Symbol Table (UST), and 
the Macro Symbol Table (MST). 

Permanent symbols consist of the PDP-11 instruction 
mnemonics and MACRO directives. The PST contains all 
the permanent symbols automatically recognized by MA- 
CRO and is part of the assembler itself. Since these sym- 
bols are permanent, they do not have to be defined by the 
user in the source program. 

User-defined symbols are those used as labels or defined 
by direct assignment. Macro symbols are those symbols 
used as macro names. The UST and MST are constructed 
during assembly by adding the symbols to the UST or MST 
as they are encountered. 


Directives 

A program statement can contain one of three different 
operators: a macro call, a PDP-11 instruction mnemonic, 
or an assembler directive. MACRO includes directives for: 
Listing control. 

Function specification. 

Data storage. 

Radix and numeric usage declarations. 
Location-counter control. 

Program termination. 

Program boundaries information. 

Program sectioning. 

Global symbol definition. 

Conditional assembly. 

Macro definition. 

Macro attributes. 

Macro message control. 

Repeat block definition. 

Macro libraries. 


Program 
Development 
and 

support 


Facilities 


VAX/VMS'‘s powerful and sophisticated program development environment in- 
cludes several support facilities. Described in this section are the interactive 
and batch text editors, the linker, the Common Runtime Procedure Library, the 
VAX-11 interactive Symbolic Debugger, the librarian utility, command lan- 
guage procedures, the differences utility, VAX-11 RUNOFF, and the optional 
DEC/CMS, Code Management System. 


In addition to the interactive text editor, SOS and the SLP batch editor, 
VAX/VMS now supports the powerful interactive text editor, EDT. EDT sup- 
ports many user-oriented features including both line and character editing fa- 
cilities, an extensive HELP facility, a journaling facility, and the window-editing 
facility. 

The VAX/VMS linker is the program development tool that takes object mod- 
ules and binds them into an image that can be executed by the VAX system. 


The Common Runtime Procedure Library offers the user a set of common 
language routines that can be called from any of the native mode languages via 
the VAX-11 calling standard. 


The VAX-11 interactive Symbolic Debugger is extremely useful in isolating pro- 
gram errors by allowing the user to examine and modify the contents of mem- 
ory locations while the program is executing. 


The librarian is a utility that allows users easy access to the data stored in any of 
the four libraries (object, macro, help, and text). The librarian allows an execut- 
ing program to initialize and open a library and to retrieve, insert, and delete 
modules. 


The command language procedure section describes the power and flexibility 
of executing strings of frequently used sequences of DCL commands, or 
creating new commands from the existing DCL command set. Command pro- 
cedures can accept up to eight parameters and can include extensive control 
flow. 


By utilizing the DIFFERENCES utility, the user can determine whether or not 
two files are identical. 


VAX-11 RUNOFF, a document formatter, offers the user such features as page 
and title formatting, subject matter formatting, and the ability to produce in- 
dexes and tables of contents easily. 


INTRODUCTION 

VAX/VMS provides a complete program development en- 
vironment for the user. Development tools supporting this 
environment are: 

® Interactive and batch text editors 

® Linker 

® Common Runtime Procedure Library 

® VAX-11 interactive Symbolic Debugger 

® Librarian Utility 

® Command Language Procedures 

® Differences Utility 

® VAX-11 Runoff 

® Optional VAX-11 DEC/CMS code management system 


These tools, as well as program language compilers, are 
available to the programmer via the command language 
facility. In addition, VAX/VMS supports a complete set of 
sharable routines collectively known as the common run- 
time procedure library. Finally, VAX/VMS supports the 
user’s ability to write programs utilizing the DCL command 
set (similar to coding programs in other high-level lan- 
guages). These programs are known as command lan- 
guage procedures. 


The text editors can be used to create memos, documen- 
tation, and text and data files, as well as source program 
modules for any language processor. The linker, librarian, 
debugger, and runtime procedure library are used only in 
conjunction with the language processors that produce 
native code. 


TEXT EDITORS 

Text editing refers to the process of creating, modifying, 
and maintaining files. VAX/VMS supports three text edi- 
tors: two interactive text editors (SOS and EDT) and a 
batch-oriented text editor (SLP). 


The user invokes the SOS and EDT text editors interac- 
tively; i.e., the user creates and processes files online. The 
SLP text editor, on the other hand, allows direct modifica- 
tion to a file via a command file prepared by the user. EDT 
or SOS can be used to create SLP command files. All edi- 
tors are invoked by the command EDIT. The default editor 
is EDT. Therefore, to invoke EDT, enter the command 
EDIT; to invoke SOS, enter EDIT/SOS; for SLP, use 
EDIT/SLP. 


Before describing the text editors, a short summary of file 
naming conventions and default file types is presented. 


File Names and File Types 

By taking advantage of the default disk and directory, the 
user can identify a file uniquely by specifying its filename 
and filetype, illustrated in the following format: 


filename.typ 


The filename, which can be from one to nine alphanumeric 
characters, can assume any name that is meaningful to the 
user. 


The filetype, a three-character identifier that's preceded by 
a period, describes more specifically the kind of data in 
the file. Although filetype can consist of any three alphanu- 
meric characters meaningful to the user, several filetypes 
have standard meanings. Among the special filetypes are: 
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File Type Default Use 


.FOR FORTRAN language source statements 
.MAR MACRO assembly source statements 
.COB COBOL language source statements 
.BAS BASIC language source statements 
.PAS PASCAL language source statements 
.DAT A data file 

LIS An output listing from a compiler 

.EXE An executable image 

.OBJ An output file from a compiler 


For example, a file containing FORTRAN source state- 
ments would possess the filetype .FOR. 


EDT EDITOR 

EDT, an interactive text editor, is the default editor with 
VAX/VMS. This editor lets users enter and manipulate text 
and programs. EDT, with its extensive HELP facility, was 
designed to be learned easily by novices. In addition, EDT 
provides many capabilities that will appeal to advanced 
users. 


What EDT Does 

EDT is a powerful text editor that provides: 

® Both line-editing and character-editing facilities. 

© Screen editing and keypad editing on the VT52 and 
VT 100 video terminals. 

® Ability to work on multiple files simultaneously. 

® A journaling facility that protects against loss of edits 
due to system crashes or loss of carrier on a dialup line. 

® An extensive HELP facility. 

® A startup command file that allows a choice of editing 
options to be set automatically 

® A window into a file (on video terminals only) that lets 
users view changes in file contents immediately. 

® Sharable installation for multiple users. 


EDT is also supported on hardcopy terminals and video 
terminals other than the VT52 and VT 100. 


EDT SPECIAL FEATURES 


Editing with a Window 

“Window editing” is a valuable feature that lets users edit 
one 22-line window (screenful) at a time. This feature al- 
lows a user to see immediately how the edits made affect 
his file. The user can position the window anywhere in the 
file. Window editing is illustrated in Figure 8-1. 


Startup File 

When the editor is started, it executes commands from a 
startup file. In this file, one can insert editing options such 
as SET NOKEYPAD and DEFINE KEY. These options take 
effect automatically when an editing session begins. 


HELP Facilities 

The HELP facilities on EDT are extensive. Users can get 
help on general EDT operations by typing HELP. While in 
keypad mode, users can get help by pressing the help key; 
doing this displays a picture of the keypad and provides 
additional information on each of the keypad keys. 


22 LINE 
WINDOW 


Figure 8-1 
Window Editing 


The Keypad 

The keypad is a special set of keys located to the right of 
the main keyboard. Figure 8-2 illustrates the functions of 
the VT100 keypad; the VT52 keypad is similar. 


FINO UND L 
SHIFT HELP 
FNDNXT | DEL EL 
piv FE (ell hence 
PAGE SECT | APPEND | DEL EW 
ADVANCE |BACKuUP | CUT DEL C 
DEL EOL | INSCOD 
SUBS 
WORD EL CHAR 
OPEN LINE RESET 
ENTER 
LINE SELECT 
Figure 8-2 
VT100 Keypad Functions 


Keypad functions allow the user to perform a variety of op- 
erations. Furthermore, the function of any keypad key can 
be changed to meet the needs of the user via the DEFINE 
command. 


The commands in the keypad submode let users alter text 
or change the cursor position in the file. Keypad functions 
are available to advance or move back the cursor or move 
the cursor to the top or bottom of the text. It is also possi- 
ble to move the cursor any number of characters, words, 
lines, or pages ata time. 


Keypad keys let a user select a string of text and move it 
elsewhere in any file. You can even find the next occur- 
rence of certain text and delete or replace it. And there is 
also a key to press for help messages. 


Redefining Keypad Keys 

It is possible to redefine any of the keypad keys and most 
of the control (CTRL) keys on VT52 and VT100 terminals. 
This feature lets the user assign a series of commands toa 
key; EDT performs these commands when the keys are 
pressed. Therefore, you can adapt the functions of keypad 
and CTRL keys to meet special needs. 
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The SET and SHOW Commands 

The SET command, with a variety of qualifiers, controls 
EDT’s editing capabilities. SET controls such screen par- 
ameters as line width or lets a user determine the appear- 
ance of text (for instance, changing the window size to less 
than 22 lines). The SHOW command provides such infor- 
mation on the current state of the editor as terminal 
parameters, definitions of keypad keys, and the names of 
buffers in use during the editing session. 


Journal Processing 

Journal processing protects the user’s work against un- 
likely system crashes. During an editing session, EDT 
saves all the terminal input in a journal file. After a crash 
and recovery, the user can choose to retrieve and execute 
commands in this saved file with the /RECOVER EDIT 
command qualifier. In this way the user can recover edited 
files to the time of the crash. 


The EDT CAI Program 

Also available with VAX/VMS EDT is a Computer-Aided 
Instruction (CAI) program on EDT. This interactive pro- 
gram presents “Introduction to the EDT Editor’, a mini- 
course that demonstrates how to use EDT. The CAI pro- 
gram, which runs on VT100 terminals, takes about three 
hours. 


EDT Modes of Operation 

A “mode” in EDT is a state in which the editor lets a user 
perform a specific set of functions. EDT has two basic 
modes of operation: line mode and change mode. 


Line mode allows users to establish editing parameters 
and to display and edit text by range specification. (You 
can specify a range with such entities as line numbers and 
character strings.) 


You can also modify the text with line-editing commands 
such as COPY, SUBSTITUTE, and REPLACE. And you can 
move about the text by using the FIND and TYPE com- 
mands, for example, or by pressing the RETURN key. 


Change mode lets users operate on such entities as char- 
acters, words, sentences, paragraphs, and lines. Users 
can also work with strings of text and can delete and move 
entire pages. EDT lets a user redefine these entities to 
tailor them to specific applications. The redefinition proc- 
ess can be as diverse as documentation or programming. 


Change mode consists of aset of NOKEYPAD commands. 
Typing any of these commands lets a user perform useful 
functions. By typing FNDNXT, for example, you can find 
the next occurrence of a string of characters. 


With VT52 and VT100 terminals, you can also use KEYPAD 
commands. The set of keypad keys, as well as several 
CTRL keys, lets the user enter any of the NOKEYPAD com- 
mands by simply pressing a key. Users can also redefine 
the functions of these keys. 


SOS EDITOR 

SOS is a line-oriented interactive text-editing program. 
SOS has features that allow examination and modification 
of text, character by character. SOS can be used to per- 
form the following functions: 


e Examine, create, and modify ASCII files. 


® Search for and/or change one or more arbitrary text 
string, with the option to verify each change before it is 
made. 


© Merge parts of one file into another. 
e Create a file that is a subset of another file. 


SOS is line-oriented, so it usually operates with line-num- 
bered text files. If a file is edited that does not contain line 
numbers, the editor adds line numbers to the text lines. 
For most SOS commands, a line number or range of line 
numbers specifies the text to be operated on. When com- 
manded to insert, delete, move, or copy text, SOS main- 
tains line numbers in ascending order within each page of 
text. 


Advanced features of SOS allow considerable flexibility in 
searching for a string of text. They furthermore allow spec- 
ification of blocks of text by content and relative position 
from a known location, instead of by line number. SOS has 
many operational features under user control. 


Initiating and Terminating SOS 
SOS is initiated by entering one of the following 
commands in response to the command language prompt 
($): 

$ EDIT/SOS filespec <RET> 


If the user were to omit filespec, SOS would immediately 
prompt the user for the missing parameter. 


To terminate SOS, enter the command E (EXIT) followed 
by a carriage return after SOS’s prompt (*). 


*E<RET> 
[filespec] 


$ 


Upon terminating, SOS writes an output file containing all 
the modifications made in editing the file. The original file 
is not changed. The specifier SOS uses for the output file 
has a version number that is higher by one than the latest 
version of the original file, unless otherwise specified by 
the user. 


SOS Examples 
Copy command 
1) ©300,9000:9500 
Make a copy of lines numbered 9,000-9,500 and 
insert the lines after line 300. 


Find command 


1) Fmore<ESC> 
Search for “more” from the current point in the 
file. 

2) Fmore<ESC>,1:1000 


Search for the first occurrence of “more” in the 
range of lines from 1 through 1,000. 


Print command 


1) P500:800 
Print lines 500 through 800. 
2) P1800 


Print line numbered 1,800. 


Substitute command 
1) Smore<ESC>less<ESC>,500:800 
Change all occurrences of “more” into “less” on 
lines numbered 500 through 800. 


8-3 


SLP EDITOR 

SLP is the batch-oriented editing program used for source 
file maintenance. SLP allows updating (deletion, replace- 
ment, addition) of lines in an existing file. The SLP com- 
mand file provides a reliable method of duplicating the 
changes made to a file. 


Input to SLP consists of a correction input file that is to be 
updated and command input containing text lines and edit 
command lines that specify the update operations to be 
performed. SLP locates lines to be changed by means of 
locators (line numbers or character strings). Command in- 
put normally enters through an indirect file that contains 
commands and text input lines to be inserted into the file. 
Alternatively, commands can be entered from the termi- 
nal. 


SLP output is an optional listing file and an updated copy 
of the corrected input file. SLP provides an optional audit 
trail that helps keep track of the update status of each line 
in the file. The audit trail, which is provided in the listing, is 
included permanently in the output file. When a given file is 
updated with successive versions of an SLP command file, 
different audit trails can be used to differentiate between 
changes made at various times. 


SLP output qualifiers permit the user to create or suppress 
an audit trail, eliminate an existing audit trail, specify the 
length and beginning position of the audit trail, or generate 
a double-spaced listing. 


Initiating and Terminating SLP 

SLP is initiated via the command language EDIT com- 
mand. The normal way to use SLP is to specify an indirect 
command file that informs SLP which files to process and 
indicates the editing changes that are to be made to the 
correction input file. The indirect file can be specified on 
the same line with the EDIT command or on a separate 
line. The indirect file must be created before running SLP. 
An interactive text editor is normally used to create SLP in- 
direct command files. If both new and old versions of the 
file exist, the differences utility can be used to create a SLP 
correction file that will change the old file into the new one. 


SLP Input and Output Files 

SLP requires two types of input: a correction input file and 
command input. The correction input file is the source file 
to be updated using SLP. Command input consists of an 
initialization line followed by SLP edit commands that indi- 
cate how the file is to be changed. 


SLP output consists of a listing file and an output file. The 
listing file, which is a copy of the output file with sequence 
numbers added, shows the changes SLP makes to the 
correction input file. The output file is the permanently up- 
dated copy of the input file. 


Correction Input File 

The correction input file is the file to be updated by SLP. It 
can contain any number of lines of text. When SLP 
processes the correction input file, it makes the changes 
specified by SLP edit commands in the output file. 


SLP Output File 

The SLP output file is the updated input file. All of the up- 
dates specified by the command input are inserted in this 
file. An audit trail, unless suppressed, is applied to lines 


changed by the update. The numbers generated by SLP 
for the listing file do not appear in the output file. 


LINKER 

Before a source-language program can be run on 
VAX/VMS, it must be assembled or compiled by a lan- 
guage processor and then linked. The language proces- 
sors translate user-written source programs into object 
modules. The VAX-11 Linker binds these object modules 
into an image that can be executed by the VAX system. 


Not all computer systems employ a linker; in some, the 
work of the linker is assumed by the language processors 
and by what is called a “loader.” But the linker offers pro- 
grammers on VAX/VMS greater flexibility in choosing and 
mixing languages; it simplifies and extends the modern 
approach of modular programming. 


Input to the Linker 

There are two basic forms of input processed by the linker: 
object modules and sharable images. They are introduced 
to the linker as part of the input files specified in the LINK 
command. The linker will accept one or more of the follow- 
ing kinds of input files: 

e Object file 

e Sharable image file 

e Symbol table file 

e Library file 


e Options file 


The object file can contain one or more object modules. 
This file has file-type .OBUJ. It is the fundamental input to 
the linker. Note that at least one object file must be speci- 
fied with any LINK command. 


The sharable image file is the product of a previous linking 
operation, but by itself is not executable. It can serve only 
as input to another linking operation. The sharable image 
file can only be specified in the options file and is indicated 
there by the /SHARABLE qualifier. 


The symbol table file is also a product of a previous linking 
operation. It can be specified when linking so that the 
linker can use the symbol values to resolve undefined 
symbols in other object modules. A symbol table file has 
the file type STB. 


There are two kinds of library files: object and sharable im- 
age. Of these there are both system libraries (maintained 
by VMS) and user Libraries (created by the DCL com- 
mand, LIBRARY). Library files are used by the linker either 
to resolve undefined symbols or as a source for particular 
object modules or sharable images specified with the /IN- 
CLUDE qualifer in the LINK command. 


The options file is not really input to the linker, in the same 
sense the other files mentioned are input; rather, it is a tool 
for managing the linking operation and for simplifying the 
use of complex and often-repeated linker operations. 
(This is, in a way, analogous to the use of DCL command 
procedures for complex or commonly used command se- 
quences). A linker options file can contain one or more in- 
put file specifications, including qualifiers or special linker 
options that cannot be specified in the DCL LINK com- 
mand line. 
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Output of the Linker 
The Linker will generate one of three types of images: 


e Executable 

e Sharable 

e System 

and an optional image map and/or symbol table. 

The most common output of the linker is the executable 
image. It is the end product of program development. It 
has the filetype .EXE and can be run by the DCL com- 
mand, RUN. 

A sharable image, on the other hand, cannot be executed 
directly. It must be linked with one or more object module, 
to produce an executable image. It contains an image 
header, one or more image sections, and a symbol table 
that defines universal symbols in the sharable image. 

A system image is one that does not run under the control 
of the operating system, but is intended to run stand-alone 
ona VAX. VAX/VMS is a system image. 

If the /MAP qualifier is specified in the LINK command, the 
linker will generate one or more of the following (at the 
users option) is an image map file: 

An object module synopsis. 

An image section synopsis. 

A program section synopsis. 

A list of symbols by name. 

A list of symbols by value. 

Link run statistics. 

If the /SYMBOL_TABLE qualifier is specified, the linker will 


generate a symbol table file tat can serve as input to a sub- 
sequent linking operation. 


Action of the Linker 

In the process of creating an image, the linker performs 
three major tasks: 

e resolution of symbolic references 

e allocation of virtual memory 

e image initialization 


The following sections describe these processes in some 
detail. 


Resolution of Symbolic References 

A symbol is a name associated with a program location or 
a value. Any reference to a symbol, other than the defini- 
tive reference, must be resolved. For example: 


JMP SYMBOL_1 (Jump to where?) 
or 

ADD SYMBOL_A,SYMBOL_B 
(Add what to what?) 


Somewhere, SYMBOL_1 must be defined as a location of 
an instruction or the beginning of a subroutine. Similarly, 
SYMBOL_A and SYMBOL_B must have values assigned to 
them. 


References to local symbols (that is, symbols defined and 
used entirely within the module) are resolved by the lan- 
guage processor, but references to global symbols (those 
that can be referred to by modules other than the defining 
module) and universal symbols (those referenced outside 
of a sharable image) must be resolved by the linker. 


Since universal symbols are, in fact, global symbols that 
are available to modules outside of a sharable image, the 
process whereby the linker resolves global and universal 
symbols is the same. During its first pass through the link- 
ing operation, the linker records each symbol reference 
and definition in a global symbol table. When the linker 
seeks to resolve a symbol reference, it first searches mod- 
ules named in the command line (with /INCLUDE), then 
user libraries, then system default libraries. 


Memory Allocation 

By the end of its first pass, the linker has processed all the 
input modules and library modules needed to resolve un- 
defined symbols. It also knows how large the final image 
will be, but it still needs to organize the image and allocate 
virtual memory. 


The linker organizes the image on three levels: cluster, im- 
age section, and program section. 


Clusters are determined in three ways: 

e The default cluster (generated by the linker). 

e User-defined clusters (generated by the /CLUSTERS= 
option). 

e Sharable image clusters (one for each sharable image). 


Image sections are created by gathering program sections 
(p-sects) with similar attributes. Those attributes include 
writability, executability, sharability, position-indepen- 
dence, and protected vector. 


Program sections and their attributes are determined by 
the language and, optionally by the user, either through 
directives to the language processor or by the 
/PSEC_ATTR option in the linker options file. 


The linker processes each cluster, one at a time—with the 
exception of nonbased, or position-independent, sharable 
images, which are allocated virtual memory by the image 
activator at runtime. In processing all other clusters, the 
linker organizes the p-sects within each cluster into image 
sections. Then the clusters are assigned virtual address 
space and the image section descriptor (ISD) of each im- 
age section is updated to include the starting virtual ad- 
dress of the image section. 


Image Initialization 

After resolving references and allocating memory, the 
linker fills in the actual contents of the image. Primarily, 
initialization consists of copying all data and code into a 
single image; but the linker performs two other functions 
at this stage: 

e Computes values that depend on externally defined 

fields. 


e Inserts these valuse into the referencing location. 


Fix-up Image Section 

Once it has initialized the image, the linker will generate a 
special image section called the fix-up image section. This 
image section contains the code that makes otherwise po- 
sition-dependent sharable images position independent. 


The general addressing mode is used to reference rou- 
tines and data contained in a sharable image. The linker 
converts general addressing mode directives into long- 
word deferred addressing mode, with indirecion going 
through the fix-up image section. Failure to use general 
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addressing mode when referencing a sharable image will 
elicit a warning message. 


All DIGITAL VAX-11 high-level language products gener- 
ate position-independent code. 


Sharable Images 

An important benefit of the linker — perhaps the most im- 
portant benefit — is that it allows the use of sharable im- 
ages. An effective application of sharable images can help 
to conserve valuable resources in the users operating 
environment. For example, physical memory require- 
ments would be reduced if global sections (one for each 
image section of a sharable image) used commonly 
among processes could be resident in memory and 
mapped into their address space; this would allow the 
same physical pages satisfy a number of processes, re- 
ducing duplication. So, too, can the user conserve disk 
storage and reduce paging I/O, when sharing replaces du- 
plication. 


One of the reasons modular programming is so attractive 
is that a commonly used routine or function can be devel- 
oped or modified once, then incorporated into any number 
of programs. The use of sharable images carries this effi- 
cient practice a step further. The modules that make up a 
sharable image are linked only once, so the overhead of 
resolving undefined symbols (within the image) and 
generating image sections — the bulk of the linkers work 
— is incurred only once, facilitating another level of modu- 
lar hierarchy. Furthermore, since a nonbased, or position- 
independent sharable image is allocated virtual memory 
by the image activator at runtime, the code it comprises 
can be modified and updated without having to relink ev- 
ery program that uses that image. 


The LINK Command 
The linker is run by the DCL command: 


$ LINK [/command-qualifier...] file-spec [/file-quali- 
fier...]... 


At least one input file must be specified. There can be mul- 
tiple command qualifiers, multiple file specifications, and 
multiple qualifiers for each file specified. 


COMMON RUNTIME PROCEDURE LIBRARY 
The VAX-11 Common Runtime Procedure Library (RTL) 


comprises of a set of general purpose and language-spe- 
cific VAX procedures that establish a common runtime en- 
vironment for all user programs written in any native-mode 
language. Because all of the language support procedures 
follow the same programming standards and make non- 
conflicting assumptions about the execution environment, 
a user program can comprise modules written in different 
languages, including assembly language. Because of the 
VAX procedure-calling standard, each native-mode user 
module can call any other native-mode user module or any 
of the procedures in the Runtime Library. 

Most of the VAX-11 Runtime Library is constructed as a 
separate sharable image that is accessed by users via en- 
try point vectors. This allows for : 

e Installation of a new library without the need to relink a 

user’s program. 


e Implementation of new internal algorithms without re- 
linking all user programs. 


e A single copy of the library that can be shared by all 
processes. 


Each procedure entry point in the sharable image is at an 
address defined relative to the base of the sharable sec- 
tion; the address will never change, once it has been as- 
signed. New entry points are always added at the end of 
the list of entry-point vectors. The entry-point vector con- 
tains the procedure entry mask and a transfer of control to 
the procedure. Use of entry vectors permits a single, 
position-independent copy of the library to be bound to 
different virtual addresses in processes that are sharing it. 
Use of entry vectors also permits a new release of the li- 
brary to be installed without requiring that user images be 
relinked. 


The VAX-11 Runtime Library is designed as a set of modu- 

lar reentrant procedures comprising several functional 

groups. They are: 

e A resource allocation group (virtual memory, logical unit 
number, and event flags). 


e A condition-handling group (signaling exception condi- 
tions and declaring condition handlers). 


© A general utility group (data type conversions). 


e A mathematical group (single and double precision tri- 
gonometric, logarithmic, and exponential functions). 


e A language-independent support group (error handling 
and Record Management Services support functions). 

e Language-specific support groups (file handling sup- 
port functions). 


e Astring-handling group (static and dynamic string 
functions). 


Resource Allocation group (LIBS) 

The resource allocation group includes all procedures that 

allow allocation of process-wide resources. Such re- 

sources include: 

e Virtual Memory — one procedure to allocate and one to 
deallocate arbitrary-sized blocks of process virtual 
memory. 


e Logical Unit Numbers — allow logical unit numbers to 
be allocated in a modular manner. 


e Event Flags — allow event flags to be allocated in a mo- 
dular manner. 


In most cases, the resource allocation procedures must be 
used to allocate process-wide resources in order for all li- 
brary, DIGITAL, and customer-written procedures to work 
together properly within an image. 


Signaling and Condition Handling 

The VAX-11 condition-handling facility is a collection of li- 
brary procedures and system services that provides a 
unified and standardized mechanism for handling errors 
internally in the operating system, Runtime Library, and 
user programs. In some cases, the mechanism is also 
used to communicate errors across these interfaces. In 
particular, all error messages are printed via this mecha- 
nism. When an error condition is signaled, the process 
stack is scanned in reverse order. Establishing a handler 
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provides the programmer with some control over fix-up, 
reporting, and flow of control on errors. It can override the 
standard error messages in order to give a more suitable 
application-oriented user interface. 


General Utility (LIBS) 

General utility procedures are not mandatory for you to 
use the rest of the library successfully. They are provided 
for the convenience of the user only. General utility pro- 
cedures include outputting a record to a logical device 
(SYSSOUTPUT). 


Mathematical Functions (MTH$) 

The mathematical library consists of standard procedures 
that perform common mathematical functions — like tak- 
ing the sine of an angle. The standard entry points have 
one or two call-by-reference input parameters and a single 
function value. Some frequently used procedures also 
have call-by-value entry points that are called by the JSB 
instruction. 


Language-Independent Support (OTS$) 

The language support libraries support the code gener- 
ated inline by compilers. As such, most of the procedures 
are called implicitly as a consequence of a language con- 
struct specified by the user, rather than being called expli- 
citly by the user with a CALL statement. Those language 
support procedures, which are independent of higher- 
level language, use the facility prefix OTS$. They include: 

e Datatype conversion. 


e Language-independent initialization and termination. 
e Error and exception-condition-processing procedures. 


Language-Specific Support (FOR$, BAS$) 

Each of the language-specific support libraries is com- 
posed of five principal types of procedures: 

e |/O-processing procedures 

e File-processing procedures 

e System procedures 

© Compatibility procedures 

© Compiled-code support procedures 

String Processing (STR$) 

The string-processing procedures allocate and deallocate 


dynamic strings and perform a number of useful string 
functions on any class of VAX strings. 


System Procedures 

VAX-11 programs written in the higher-level languages 
can call the operating system directly. However, since 
some languages cannot easily pass arguments in the form 
that system services require, and since some languages 
use data types that system services cannot properly han- 
dle (i.e., dynamic strings), LIB$ routines provide easy ac- 
cess to the operating system directives. 


Compiled-Code Support Procedures 

These routines complement the compiled code by per- 
forming operations too complicated or too cumbersome to 
perform directly with inline code. Thus, the language 
support libraries support the code generated by the com- 


piler. For example, division of complex numbers is per- 
formed by a library procedure. 


Error Processing Procedures 

Errors detected by the Runtime Library are indicated by 
returning an error completion status wherever possible. 
This is especially true for the general utility library (LIB$). 
However, the math library and the language support librar- 
ies indicate most errors by CALLing the VAX-11 
LIB$SIGNAL or LIB$STOP procedures. The LIB$SIGNAL 
procedures use a condition value as an argument that has 
an associated error message stored in a system error 
message file. The condition is signaled to successive pro- 
cedure activations in the process stack. These procedures 
can have established handlers to handle the conditions or 
change the error message. Thus, an application can tailor 
its error messages to its own needs. 


VAX-11 SYMBOLIC DEBUGGER 

The VAX-11 Symbolic Debugger is a language-indepen- 
dent interactive program that can be linked with user code 
written in all native-mode languages supported by 
VAX/VMS. Current languages with which the debugger 
can be used are: VAX-11 FORTRAN, VAX-11 BASIC, VAX- 
11 COBOL, VAX-11 C, VAX-11 BLISS-32, VAX-11 CORAL 
66, VAX-11 PASCAL, and the VAX-11 MACRO assembly 
language. After linking with the user program, the DEBUG 
facility is operative in the language of the first module of 
the image file. If it is necessary to alter the language for a 
later module, the SET LANGUAGE command can be used. 


DEBUG enables dynamic examination and modification of 
the contents of memory locations; This is useful in isolating 
program errors. Since user program execution is con- 
trolled by DEBUG once it has been invoked, modifications 
can be made to the program while it is executing. 


The VAX-11 debugger includes many user-oriented func- 

tions that facilitate the use of the VAX-11 Symbolic Debug- 

ger. 

e The debugger is interactive — the user maintains 
control of the program while conversing with the debug- 
ger via the terminal. 


e The debugger is symbolic — program locations can be 
referred to by the symbols the user has created in the 
program. The debugger is also capable of displaying lo- 
cations as symbolic expressions. 


The debugger supports all native mode languages — 
the debugger lets the user converse with the program 
via the source program's language. Furthermore, the 
user can change languages during the course of a de- 
bugging session by means of a simple command. 


The debugger permits a variety of data forms — the user 
controls the way in which the debugger accepts and dis- 
plays addresses and data. For example, an address can 
be represented either symbolically or as a virtual ad- 
dress in decimal, octal, or hexadecimal. Also, data can 
be represented by symbols, expressions, VAX-11 
MACRO instructions, ASCII character strings, or nu- 
meric strings in decimal, octal, or hexadecimal. 


DEBUG Commands 
DEBUG commands direct the execution of the program. 
They can be entered interactively from a terminal or from 
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an indirect command file. Typically, the DEBUG com- 

mands can: 

e Specify points at which execution will be suspended, 
when and if they are encountered, by using the SET 
BREAK command. 


e Trace the sequence of program execution by means of 
the SET TRACE command. This command establishes 
tracepoints in the program. 

Display before-and-after values of a location whenever 
that location is stored into, by means of the SET WATCH 
command. 


Initiate or resume execution by means of the GO com- 

mand or the STEP command. 

e Determine the location of breakpoints, tracepoints, and 
watchpoints by means of the commands SHOW BREAK, 
SHOW TRACE, and SHOW WATCH, respectively. 

e Erase breakpoints, tracepoints, and watchpoints in the 
program through use of the CANCEL command. 

e Display the contents of memory locations by using the 

EXAMINE command. 

Change the value of the contents of memory locations 

by using the DEPOSIT command. 

e Obtain the value of an expression or the current address 

of a symbol or express a numeric value in a different ra- 

dix, by using the EVALUATE command. 

Call a subroutine at DEBUG time by means of the CALL 

command. 

e Change values of parameters for LANGUAGE, SCOPE, 

MODE, and TYPE. 


Specify an arbitrary file name for the DEBUG log file by 
means of the SET LOG command. 

e Control DEBUG I/O at debug time via the SET OUTPUT 
command. This includes normal terminal output, log-file 
output, and comman4d-file verification. 

Find all current output attributes (VERIFY, TERMINAL 
and LOG) by using the SHOW OUTPUT command. For 
more limited needs, aSHOW LOG command is available 
that displays only the LOG data. 


e Instruct DEBUG to take commands from a specified file 
by means of @filespec. 


VAX-11 RUNOFF 

VAX-11 RUNOFF is a document formatter. A RUNOFF- 

processed document can be updated without extensive 

retyping because text changes, via the text editors, do not 

affect the basic design. The input to RUNOFF is a file con- 

taining the text of the document and the RUNOFF instruc- 

tions. Executing in default mode, RUNOFF provides: 

e Astandard typewriter page size of 8%" x 11”. 

e Sequential page numbering for every page but the first. 

e Page width of 60 characters. 

e Single spacing. 

e Automatic tab settings for every eighth print position, 
starting with the ninth column (9,17,25, etc.). 

e Automatic filling and justifying. 

The output file is the print-ready document. After RUNOFF 

has processed the file, the original file remains available 

for further editing. 


VAX-11 RUNOFF contains commands that perform the fol- 
lowing functions: 

@ filling and justifying text 

e Page formatting. 

® Title formatting. 

@ Subject-matter formatting. 

® Graphic, list and note formatting. 

® Index and table of contents. 

® Miscellaneous formatting. 


Filling and Justifying 

RUNOFF commands set left and right margins so that the 
user can enter text without concern for line width or vari- 
able spacing between words. The RUNOFF program will 
fill and justify the text when it is run. Filling is the succes- 
sive addition of words to a line until one more word would 
exceed the right margin. RUNOFF justifies the line by ex- 
panding the spaces between words to produce an even 
right margin. 


Page Formatting 

The page-formatting commands control the appearance 
of each page of output. For example, there are page-for- 
matting commands that establish the style and location of 
chapter headings and subheads. There are other page for- 
matting commands that engage or disengage page num- 
bering, produce and format titles and subtitles, and force 
the printer to advance to a new page. 


Title Formatting 

Title-formatting commands provide page, title, and 
subtitle information for all pages. Such actions as placing 
only the chapter heading on the first page of a chapter, 
printing any subtitles of designated words, and determin- 
ing the number of header levels (up to six) that the docu- 
ment will have are provided by the title-formatting com- 
mands. 


Subject-Matter Formatting 

Subject-matter-formatting commands include managing 
the design and appearance of text, as with ragged right- 
hand margin, indenting a paragraph, skipping a number of 
lines, centering the text, underlining, hyphenation, and 
overstriking. Of course, different parts of the text can be 
formatted differently, and commands can be combined. 
To illustrate, a user has the option to have lists justified or 
to have them with ragged margins. 


Index and Table of Contents 

RUNOFF has powerful facilities for creating indexes and 
tables of contents. There is acommand to generate a one- 
column index, and the TCX program generates two-co- 
lumn indexes, while the TOC program generates tables of 
contents. Both TCX and TOC create files that can be edited 
or can be processed by RUNOFF. This adds great flexibil- 
ity to the preparation of indexes and tables of contents. 


Miscellaneous Formatting 

A number of useful RUNOFF commands help the user to 
re-establish all default values, to add nonprinted com- 
ments to the source file, to gather externally located files 
into the input, and to set time and date. 
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THE LIBRARIAN UTILITY 

Libraries are indexed files that contain frequently used 
modules of code or text. There are four types of libraries; 
object, macro, help, and text. The library type indicates the 
type of module that the library contains. Each library con- 
tains indexes that store information regarding the library’s 
content, including type and location. The librarian is a 
utility that allows the user easy access to the data stored in 
libraries. 


The librarian can be invoked in one of two ways: via a set of 
librarian routines that can be called from the user program 
directly or, interactively, via the DCL command LIBRARY 
issued from the terminal or from within an indirect com- 
mand file. The DCL LIBRARY command enables the user 
to replace and maintain modules in an existing library or to 
create a new library. The librarian routines enable an exe- 
cuting program to initialize and open a library and to re- 
trieve, insert, and delete modules. 


The four library types are defined as follows: 

® Object libraries (filetype OLB) contain frequently called 
routines and are used as input to the linker. The linker 
searches the object module library whenever it 
encounters a reference it cannot resolve from the speci- 
fied input files. 


® Macro libraries (filetyoe MLB) contain macro definitions 
used as input to the MACRO assembler. The assembler 
searches the macro library whenever it encounters a 
macro that is not defined in the input source file. 


Help libraries (filetype HLB) contain help modules that 
provide user information concerning a program. The 
help message can be retreived by calling the appropri- 
ate librarian routines. 

e Text libraries (filetype TLB) contain any sequential re- 
cord files required by the user program. A user program 
can Call library routines directly to retrieve text modules. 


Librarian Routines 

The Librarian utility provides a set of 18 user-callable rou- 
tines that: 

® Initialize a library. 

® Open alibrary. 

® Look up a key in a library. 

@ Insert a new key in a library. 

@ Return the names of the keys. 

® Delete a key and its associated text. 

® Read text records. 

® Write text records. 

The user program can call the librarian routines by using 


the VAX-11 standard calling sequence supported in all 
languages producing VAX-11 native mode code. 


DCL LIBRARY Command 

The LIBRARY command can create or modify a library 
(object, help, text, or a macro) or insert, delete, replace, or 
list modules, macros, or global symbol names in a library. 


To invoke the LIBRARY command, enter the following for- 
mat: 


LIBRARY library[file-spec,....] 
For example, to create an object library named TESTLIB 


and insert entries ERRMSG and STARTUP, the user would 
proceed as follows: 


$LIBRARY/CREATE TESTLIB ERRMSG,STARTUP 


COMMAND LANGUAGE PROCEDURES 

A command procedure is a file containing DCL com- 
mands, command or program input data, or both. Com- 
mand procedures can be used to catalog sequences of 
commands frequently used during an interactive session 
or to submit all jobs for batch processing. 


In its simplest form, a command procedure consists of one 
or more command line that the command interpreter exe- 
cutes. In its most complex form, a command procedure re- 
sembles a program written in a high-level programming 
language: it can establish loops and error-checking pro- 
cedures, call other procedures, pass values to other pro- 
cedures and test values set in other procedures, perform 
arithmetic calculations and input/output operations, and 
manipulate character-string data. 


Passing Parameters to Command Procedures 

The user can write generalized command procedures that 
can perform differently each time they are executed. The 
command interpreter defines eight special symbols for 
use aS parameters within command procedures. These 
symbols are named P1, P2, P3...P8. They are all initially 
equated to null strings. Either numeric or character-string 
values for these parameters can be passed when execut- 
ing the procedure with the @ command or the SUBMIT 
command when entering a batch job. 


For example, the procedure named EXECUTE contains 
the following lines: 


$ IF P2 .EQS. “” THEN $P2:=“FORTRAN” 
$ ‘P2’‘P1’ 

$ LINK ‘P1’ 

$ RUN ‘P1’ 


The command procedure, EXECUTE, accepts both the 
language compiler and the user program name as input. If 
the user executes the procedure with the @ command, the 
values for the command parameters P1 and P2 would be 
entered as follows: 


$ @EXECUTE PAYROLL COBOL 
In this sample run, the user chose the program name PAY- 
ROLL, and the COBOL compiler. 


It is also possible to define a symbol as a local symbol via 
an equals sign in an assignment statement. For example, 
the user might have equated the symbol EXE to the execu- 
tion command @EXECUTE as follows: 


$ EXE*CUTE:=@EXECUTE 
The asterisk (*) specifies that EXE, EXEC, EXECU, etc. are 
abbreviations of EXECUTE. The minimum abbreviation is 
three characters (in this case, EXE). A colon (:) in an as- 
signment statement indicates a character-string 
assignment. To execute the command procedure, the user 
can enter the following: 


$ EXE STRESS 
In this run, STRESS is the user program name; the com- 
piler is the default compiler, FORTRAN (i.e., the second 
parameter in the EXE command was left blank). 
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Logical Commands 

Normally, the command interpreter executes each com- 
mand in a command procedure in sequential order; it ter- 
minates processing when it reaches the end of the com- 
mand procedure file. However, by using combinations of 
the logical commands, the user can alter the flow of 
execution of the command procedure. By using the IF, 
GOTO, ON, EXIT, and STOP commands, the user can con- 
trol the execution sequence and can conditionally execute 
lines, construct loops, and handle errors. 


Lexical Functions 

The command interpreter recognizes a set of functions, 
called lexical functions, that return information about char- 
acter strings and attributes of the current process. Lexical 
functions can be used in any context in which symbols and 
expressions are used. Within command procedures, lexi- 
cal functions are used to translate logical names, perform 
character-string manipulations, and determine the current 
processing mode of the procedure. 


Command Procedure Example 

The command procedure described in Figure 8-3, when 
invoked, locks up a user terminal. If a user must leave the 
terminal for some time and does not wish to have it dis- 
turbed, that user can invoke the command procedure 
INUSE.COM. This renders the terminal inaccessible to any 
other users unless they know the access password. 


This command procedure illustrates several of the power- 

ful features of DCL, including: 

e Trapping of the Control-Y function. 

e Calling a command procedure from within a command 
procedure. ERASE, ERASELINE, and TEXT are user-de- 
fined symbols that also invoke command procedures. 

e Referencing lexical functions (i.e., ‘FSTIME, ‘FSLOCATE, 
and ‘F$EXTRACT). 


Upon invoking the command procedure INUSE.COM: 

e The current setting of VERIFY is retrieved via the lexical 

function ‘FSVERIFY and stored in local variable VER 

(line 100). 

The procedure will set NOVERIFY (line 200,); i.e., the 

command lines are not echoed on the terminal during 

execution. If verify was on when the command pro- 

cedure was invoked, it will be turned on when the pro- 

cedure exits successfully. 

e The address of the password routine (line 900) is stored 
for later use, if Control-Y is typed. 

e The address of ERR_HNDLR (line 950) is stored for 
processing any errors that might occur. 


Execution then proceeds with the BEGIN code block (lines 
1,000-1,300). The ERASE procedure (line 1,100) is called, 
which clears the screen of all text. INUSE.COM then calls 
the command procedure INUSE.TXT (line 1,300). This pro- 
cedure prints in block letters, “IN USE,” across the video 
screen. Execution then proceeds to the LOOP section of 
code (lines 1,500-2,300). This block of code retreives the 
current date and time of day from VMS, using the lexical 
function ‘F$TIME. The date and time of day normally ap- 
pear as follows: 


dd-mmm-yyyy hh:mm:ss.cc 


THIS COMMAND PROCEDURE LOCKS A TERMINAL AS BEING IN USE. IT DISABLES 
CONTROL Y, SETS A CONTROL Y ENTRY POINT AND LOOPS ON A SHOW TIME 
COMMAND. A CONTROL Y TYPED AT THE TERMINAL WILL TRANSFER CONTROL 
TO A CHECK FOR A PASSWORD TO EXIT FROM THIS PROCEDURE. 


ISHOW TIME DOWN TO MINUTES 


100 $  VER='FSVERIFY() 

200 $ SET NOVERIFY 

300 $ 

400 $! 

500 $! 

600 $! 

700 $! 

800 $ 

900 $ § ONCONTROL Y THEN $GOTO PASSWORD 
950 $ § ONERROR THEN GOTO ERR HNDLR 
1000 $BEGIN: 

1100 $ ERASE 

1200 $ 

1300 $ | COMMANDS:INUSE.TXT 

1400 $ 

1500 $LOOP: 

1600 $  TIMSTR:=‘FSTIME() 

1700 $ DOT='FSLOCATE(".”,TIMSTR) 

1800 $  DOT=DOT-3 

1900 $  TIMSTR:=‘FSEXTRACT(0,DOT,TIMSTR) 
2000 $ TEXT532""TIMSTR” 

2100 $  TEXT1 1 

2200 $ WAIT 00:01 

2300 $  GOTOLOOP 

2400 $ 

2500 $PASSWORD: 

2600 $ TEXT1 1 

2700 $ INQUIRE MAGIC "ENTER THE PASSWORD TO CONTINUE” 
2800 $ IF"“MAGIC” .EQS."“P1" THEN $GOTO EXIT 
2900 $ IF”“MAGIC” .EQS. "REFRESH” THEN $GOTO BEGIN 
3000 $  ERASELINE 1 

3100 $  ERASELINE2 

3200 $  ERASELINE3 

3300 $  ERASELINE4 

3400 $  ERASELINE5 

3500 $  ERASELINE6 

3600 $  ERASELINE7 

3700 $ § GOTOLOOP 

3800 $ 

3801 $ ERR _HNDLR: 

3802 $ | ONERROR THEN GOTO ERR_HNDLR 
3803 $  GOTOPASSWORD 

3900 SEXIT: 

4000 $  SETCONTROLY 

4100 $ ERASE 

4200 $ IF VER THEN $SET VERIFY 

4300 $ EXIT 

4400 $ 

4500 $! END OFINUSE.COM 


Figure 8-3 


Example Command Procedure 


The ‘F$LOCATE and ‘FSEXTRACT lexical functions oper- 
ate upon the date and time of day, reducing the time 
quantity to hours and seconds only. Therefore the final 
date and time of day appear as: 


dd-mmm-yyyy hh:mm 
This date-and-time-of-day function is printed on the 
screen above the “IN USE” message. The date and time of 
day are refreshed once every minute. The PASSWORD 
code (lines 2,500-3,700) is entered only if a Control-Y is 
typed at the terminal while the terminal is locked up. The 
command procedure prompts for a password. If the en- 
tered password matches the initial password (declared by 
the current user of the terminal), the flow of execution 
drops to the EXIT code block (lines 3,900-4,300). If the 
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passwords do not match, execution drops through to line 
3,000, which clears the top seven lines of the screen. 


Another added feature is the REFRESH statement. The 
REFRESH statement directly follows the PASSWORD 
check statement. If the screen gets cluttered with garbage 
characters, any user can enter a CONTROL Y, and in re- 
sponse to the system prompt for a password, type RE- 
FRESH. REFRESH is recognized, clearing the entire 
screen of unwanted characters. 


DIFFERENCES UTILITY 

By invoking the DIFFERENCES command, the user can 
determine if two files are identical and, if not, how they dif- 
fer. The DIFFERENCES utility compares the contents of 


two disk files on a record-by-record basis and then cre- 
ates a listing of the records that do not match. By default, 
the DIFFERENCES utility compares every character in 
each file and, by default, writes the output in ASCII. 


VAX-11 CODE MANAGEMENT SYSTEM 

The optional DEC/CMS (Digital Equipment Corporation 
Code Management System) comprises a set of commands 
that helps software developers manage the files of an on- 
going project. DEC/CMS enables users to: 

® Keep ASCII text files in a project library. 

® Retrieve previous file generations. 


® Receive a report containing information about the modi- 
fication. 


® Learn the origin of each line of a file, either as an anno- 
tated listing or as comments in a file. 


® Manage concurrent modifications. 
® Merge separately developed modifications. 
© Keep related files together as a single element. 


® Relate the generation of one element to the 
corresponding generations of other elements. 


Each CMS command is invoked from the operating sys- 
tem’s command level to perform a specific function, such 
as reserving a file for modification or obtaining a report of 
development status. Each command returns to the operat- 
ing system’s command level where the user can edit, com- 
pile, and test in the usual manner. Any editor and compiler 
can be used. 


All the test files for the project are stored in a project 
library where they belong to the project as a whole. Each 
project has its own library, which the user identifies at the 
beginning of the session by means of the SET CMS LI- 
BRARY command. ASCII text files, including source pro- 
grams, command files, documentation, and test data, can 
be stored in the project library. 


A project library is a collection of elements, each of which 
consists of one or more related files. For example, a 
source file and the command file that translates the file 
from source to object, might constitute an element of the 
library. Commands generally operate on entire elements, 
retrieving or storing all files of an element at the same 
time. 


For each element, the library stores successive genera- 
tions. An element generation is an historical instance of 
the element’s files. Once an element generation exists in 
the library, it never changes. A modification to a genera- 
tion is stored as a new generation. Successive genera- 
tions, each a modification of the previous, form a line of 
descent. Typically, each element generation will have one 
successor. This is the main line of descent. CMS allows 
two or more successors to a generation, forming variant 
lines of descent. 


Generation expressions allow the user to retrieve a partic- 
ular generation or the latest in a particular line of descent. 
A generation or line of descent can be identified by a gen- 
eration number or by a user defined class name. A class 
can denote a base level, a release, the current stable ver- 
sion, a debugging version, or any other characteristic 
agreed on by users. 


Historical generations of source and other text files are 
stored efficiently by storing only their differences. CMS fig- 
ures out the differences. This information enables CMS 
users to report the generation of origin of each line of a file, 
i.e., the generation in which the line was most recently in- 
serted and modified. 


A history is kept of all movements of files into and out of 
the project library. In addition, a list of reservations is kept 
for all modifications that are in progress at any time. If a 
user attempts to reserve for modification a element that is 
already reserved by someone else, the user is informed of 
this and asked whether or not to proceed anyway. If the 
answer is yes, the occurence is recorded as an unusal 
event. The other users involved will simarily be informed 
and queried when they attempt to put their modifications 
back into the library. 


Concurrent modifications are not lost; they are stored in 
the library on different lines of descent. Modifications on 
different lines of descent can be merged, and the result 
can be edited to resolve any conflicting modifications. 


Here if a brief description of the principal DEC/CMS sub- 
commands: 


RESERVE Places a copy of a generation in the 
user’s working directory and notes that 
the user is working on a modification for 
it. The entire element is reserved against 


concurrent modification by another user. 


REPLACE Creates a new generation of an element 
that the user has reserved. The files of 
the new generation are moved to the 
project library from the user’s working 


directory. 


The new generation is a successor of the 
generation the user obtained when the 
element was reserved. 


Similar to RESERVE, except that the ele- 
mentis not reserved for modificaion. The 
copy placed in the working directory can 
not be used to create a new generation 
of the same element. 


SIMILAR 


UNRESERVE Cancels an existing reservation of an ele- 


ment. 


ANNOTATE Produces an annotated listing of any ele- 
ment in the library. The annotations 
describe the element and its ancestors 
and indicate the origin of each line of the 
element (i.e., the generation in which 
each line was inserted or most recently 


modified). 


Displays chronological and status infor- 
mation. For any generation, the com- 
mand can give the author, creation date, 
creating command, and author’s remark. 
This information can also be obtained for 
a generation’s ancestors or descen- 
dents. The command can also list all 
elements of the library, all that are re- 
served, or all that have a generation ina 
given class. All or a portion of the project 


SHOW 


CREATE 
INSERT 
SET LIBRARY 


VERIFY 


history can be displayed, and the display 
can be restricted to unusual events. 


Creates a new element or class. 
Puts an element generation into a class. 


Identifies the user’s project library at the 
start of a session. 


Performs consistency checks on the li- 
brary, and recovers from a malfunction 
by nullifying a partically completed 
transaction. 
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OPERATING SYSTEM 


VAX/VMS information management includes a file system that provides vol- 
ume structuring and protection and record management services that provide 
device-independent access to the VAX peripherals. 


VAX/VMS also supports a structure of layered products that are used to organ- 
ize, maintain, retrieve, and manipulate data quickly, easily, and cost-effectively. 


The VAX/VMS ondisk structure provides a multilevel hierarchy of named direc- 
tories and subdirectories. Files can extend across multiple volumes; they can 
be as large as the volume set on which they reside. Volumes are mounted to 
identify them to the system. VAX/VMS also supports multivolume ANSI-format 
magnetic tape files with transparent volume switching. 


The VAX/VMS record management input/output system (RMS) provides 
device-independent access to disks, tapes, unit record equipment, terminals, 
and mailboxes. RMS allows user and application programs to create, access, 
and maintain data files with efficiency and economy. Under RMS, records are 
regarded by the user program as logical data units that are structured and ac- 
cessed in accordance with application requirements. 


RMS provides sequential record access to sequential file organizations; se- 
quential, random, or combined record access to relative file organizations; and 
sequential, random, or a combination using index key access to multikey in- 
dexed files. Multikey indexed file processing includes incremental 
reorganization. 


VAX/VMS supports information management facilities includes DATATRIEVE, 
VAX-11 Common Data Dictionary (CDD), VAX-11 DBMS (Database Manage- 
ment System), VAX-11 SORT/MERGE, and VAX-11 FMS (Forms Management 
System). 


INTRODUCTION 

Information management refers to the complete set of 
software capabilities a computer system provides for han- 
dling and managing data. Information management soft- 
ware usually falls into three general levels of capabilities: 

® file management 

® data management 

© database management 


File management, the most basic software capability, re- 
quires programmers to deal with data in single unrelated 
files, using traditional programming languages like 
COBOL and FORTRAN. Most file management software 
requires that each application program precisely describe 
the data — how it will be used — within the logic of the pro- 
gram. Data security is usually provided by the operating 
system or by the application program itself. 


Data management systems are more sophisticated. More 
user-oriented tools are supported. Query languages and 
report writers; a high-level language that can be used for 
writing whole applications; aids for the programmer, such 
as the ability to deal with logical records through the use of 
data dictionaries; additional security features; and a higher 
degree of program/data independence are some exam- 
ples. 


Database management, the most sophisticated level, al- 
lows for true program/data independence. It also provides 
comprehensive security and data integrity features, along 
with sophisticated techniques for modeling data structures 
and data relationships. 


The VAX/VMS information management services are pro- 
vided by the following facilities: 
® file system 

® record management services 
® device drivers 

® command interpreter 

® data inquiry and update 

® common data dictionary 

® database management 

® forms management 

® reordering data 


The file system provides volume structuring and directory 
access to disk and magnetic tape files. Programmers can 
use either the file system as a base on which to build their 
own record processing system, or they can use the 
VAX/VMS record management services. 


The record management services (RMS) provide device- 
independent access to all types of I/O peripherals. The 
RMS procedures enable a program to access records 
within files and provide the same programming interface, 
regardless of device characteristics. The system includes 
utilities for RMS file creation and maintenance. VAX-11 
RMS supports sequential, relative and multikey indexed 
files. 


The device drivers provide the basic I/O device handling 
for all other data management services. Device drivers 
and their features are described in the Peripherals and 
Operating System sections. 
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As described in the Users section, the command interpre- 
ter enables a user to reserve devices for exclusive use, set 
device and directory name defaults, and assign logical 
names to file specifications. The command interpreter also 
enables the user to execute file management utilities that 
provide file copy, transfer, and conversion operations. 


Data inquiry and update is provided by VAX-11 DATA- 
TRIEVE; data ‘about data’ is stored in the VAX-11 CDD 
(Common Data Dictionary) while the actual data is stored 
elsewhere; forms management by the VAX-11 FMS 
(Forms Management System); database management by 
the VAX-11 DBMS (Database Management System); and 
the reordering of data by VAX-11 SORT/MERGE. 


The following paragraphs discuss some of the features 
and functions of the file system, including the file struc- 
tures, file-naming facilities, and the file management utility 
programs. Then the remainder of this section describes 
the information architecture and shows how the layered in- 
formation management products work together. 


FILE MANAGEMENT 

VAX/VMS provides two file structures — one for disk vol- 
umes and one for magnetic tape volumes. From the user’s 
point of view, the only differences between the two struc- 
tures are those imposed by the capabilities of the media. 
Volumes are mounted for identification, and files can 
extend across multiple volumes. The practical limit to file 
size is that it can be only as large as the volume set on 
which the files reside. 


Volume and file protection are based on User Identifica- 
tion Codes (UICs) assigned to accessors and the file or 
volume. Depending on the relationship, the accessor may 
or may not have read, write, execute, or delete access to 
any given file. 


Disk volumes are multiuser volumes. They can contain a 
multilevel directory hierarchy that is defined dynamically 
by the users of the volume. The ondisk file structure 
appears to a program to be a virtually contiguous set of 
blocks. The blocks, however, can be scattered anywhere 
onavolume. Mapping information is maintained to identify 
all the blocks constituting a file. Figure 9-1 illustrates the 
file structure. 


Disk files can be extended easily. The blocks of the file are 
allocated in physically contiguous sets, called extents. 
Users are not required to preallocate space, although they 
can do so. Users can specify placement on an allocation 
request and can control automatic allocation. For exam- 
ple, when a file is automatically extended, it can be ex- 
tended by any given number of contiguous blocks. If de- 
sired, a file can be created as a contiguous file: in such an 
instance it is both virtually and physically contiguous. 


The disk structure includes duplicates of its critical volume 
information. The system detects bad disk blocks 
dynamically and prevents their reuse once the files to 
which the bad-blocks are allocated have been deleted. 


Magnetic tape volumes are single-user volumes that con- 
sist of physically contiguous blocks. Record blocking is 
under program control. Files have ANSI-format labels. 
VAX/VMS also supports unlabeled (non-file-structured) 
magnetic tapes. 
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Figure 9-1 
Disk File Structure 


File Directories and Directory Structures 

A directory is a file containing a list of files on a given vol- 
ume. A directory entry contains the name, type, version, 
and unique file ID for a particular file. A directory can list 
files having the same owner UIC or files having different 
owner UICs. The entries are listed alphabetically. 


A disk volume contains at least one directory, called the 
master file directory. The system manager is responsible 
for creating a volume’s master file directory. The master 
file directory can (and normally does) contain a list of 
directory files that forms a second level of directories. The 
second level of directory files can list data files and/or 
other directory files, called subdirectories. Users can cre- 
ate subdirectories within the directories they own. The 
subdirectories can also list other directory files and/or 
data files. Figure 9-2 illustrates a multilevel directory struc- 
ture. 


Since directories of files on volumes are files themselves, 
they are assigned owner UICs and can be protected from 
certain kinds of access, depending on the relationship es- 
tablished by an accessor’s UIC. In the special case of 
directory files, the file protection fields control an acces- 
sor’s ability to: 

e look up files 
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e enter new files in the directory, including new versions of 
existing files 


e remove files from the directory 


File Specifications 
A file specification identifies which file is to be used in a file 
processing operation. Programs use file specifications to 
identify the file they want to create, access, delete, or ex- 
tend; users supply the command interpreter with a file 
specification to identify the file they want to edit, compile, 
copy, delete, etc. A complete file specification is a well-de- 
fined character string composed of the following fields: 

e Node Name — The node of the network in which the vol- 
ume containing the file is stored. The node name is fol- 
lowed by two colons (::) to delimit it from the remainder 
of the file specification. 


Device Name — The device on which the volume 
containing the file is mounted. The device name may be 
a logical device name or a physical device name and is 
followed by a single colon (:) to delimit it from the re- 
mainder of the file specification. 


Directory Name — The directory in which the file is 
listed. A directory name begins with an opening bracket 
(< or [) and ends with a closing bracket (> or }). If the file 


MASTER FILE 


DIRECTORY 
JONES. DIR 


[PAYROLL] MASTER. DAT 


HANOI. LIS 
TEST. COM 


BACKUP. DIR 


MASTER. DAT 


WEEKO9. DAT 
WEEK 10. DAT 


WEEK 11. DAT 


[PAYROLL. BACKUP] MASTER. DAT 


Figure 9-2 
Multilevel Directory Structure 


is listed in a subdirectory, the directories to be searched 
are listed in the desired search order, with the names 
separated by periods. For example: 


[name1.name2.name3] 
e Filename — The user-assigned name of the file. 


e Filetype — The type identification for the file. The type is 
preceded by a period (.) to delimit it from the remainder 
of the file specification. 


e File Version — the generation number of the file. The file 
version is preceded by a semicolon (;) or period (.) to de- 
limit it from the remainder of the file specification. 


For instance, a complete file specification might be: 
NODE47::DBA1:[JONES]HANOI.FOR;2 


In this case, NODE47 is the name of the network node; 
DBA1 is the name of the device (DB for disk pack device, A 
for disk controller, and 1 for drive unit number); [JONES] 
is the directory name; HANOI is the filename; FOR is the 
filetype (meaning that the file is a FORTRAN source file); 
and 2 is the version number. 


Neither programs nor command language users need to 
provide a complete file specification to identify files. The 
system applies defaults to most fields of a file specification 
when they are not present. For example, if the node name 
is not present, the node is assumed to be the node on 
which the program is executing. If the version number is 
not present, the version is always assumed to be the latest 
version. Device name and directory name defaults for 
users and the programs they execute are supplied by the 
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system manager in the user authorization file. Users can 
change the standard defaults at any time during their ses- 
sion on the system. 


Some commands (such as COPY, PRINT, BACKUP, and 
DELETE) accept a wildcard in one or more fields of a file 
specification. A wildcard is an asterisk appearing in a file 
specification field and it means “all.” 


File specifications also apply to non-file-structured de- 
vices such as lineprinters, cardreaders, and terminals. In 
these cases, however, the user or program needs to sup- 
ply only the node name and device name, as appropriate. 


Logical File Naming 

To provide both system and device independence, users 
and programs are not limited to identifying files by their file 
specifications. They can use logical names in place of a 
complete file specification or in place of a portion of a file 
specification. For example, a user can assign a logical 
name to the left-most three fields of a file specification: 


$ ASSIGN NODE47::DBA4:[JONES] VOL 


and then use the logical name VOL in a subsequent com- 
mand: 
$ TYPE VOL:HANOI.FOR 


Defaults also apply when translating logical names; so that 
the user could have also made the assignment: 


$ ASSIGN NODE47::[JONES] VOL 


In this case, the user’s default device name would be used 
to derive the complete file specification. 


Logical name assignments can be made on a process, 
group, or systemwide basis. Logical names can also be re- 
cursive; that is, a logical name can be assigned to another 
logical name or to a logical name and a portion of a file 
specification. 


For instance, suppose a company’s weekly payroll pro- 
duction run includes an application program that uses the 
current week’s payroll changes data file. That data file 
might be located in the directory named [PAYROLL] one 
week or in the payroll backup subdirectory, [PAY- 
ROLL.BACKUP], another week. The volume on which the 
file is stored could be mounted on disk-pack drive unit 
number 1 one week, or on unit 2 another week. 


The application programmer can write the program with- 
out knowing which directory the data file is listed in or 
which device the volume is mounted on. A series of logical 
name assignments provides the complete file specifica- 
tion. The assignments are the responsibility of the people 
who know what directory the file is listed in and what drive 
the volume is mounted on. 


In the example shown in Figure 9-3, the application pro- 
gram contains an OPEN statement for the payroll data file 
using the logical name WEEKLY PAYROLL _ 
CHANGES (note that underline is a legal character). The 
application systems designer has created a command 
procedure file called PAYRUN that controls the production 
run. The command procedure file includes a logical-name 
assignment that obtains the filename as a parameter sup- 
plied by the operator or production clerk who starts the 
production run. The logical name used by the application 
program is given a value that consists of another logical 
name (WEEKLY PAYROLL) and the filename and filetype 
specifications. 


To complete the series of logical name assignments, the 
payroll group operations manager makes a group-wide 
logical name assignment — the payroll data files this week 
are stored in the PAYROLL.BACKUP subdirectory. The 
logical name assignment provides the directory name, us- 


Application Programmmer: 


ing another logical name (PAY_PACK) known to the oper- 
ator who mounts the payroll data files volume. The opera- 
tor makes the systemwide logical name assignment when 
mounting the pack before the production run. Given the 
assignments shown in the example, the logical name used 
to open the file is translated to: 


DBA2:[PAYROLL.BACKUP]WEEK09.WPY 


The local system node name and the latest version num- 
ber are used as defaults to complete the file specification. 
Should the directory name change or the pack be 
mounted on another device that day, the only changes 
made are the logical name assignments. There is no need 
to modify either the application program or the command 
procedure controlling the production run. 


File Management 

The VAX/VMS system includes many services that aid in 
data management and maintenance. Some of these are 
described in the following paragraphs. 


Sorting Files — The SORT/MERGE program allows the 
user to rearrange, delete, and reformat records in a file. 
The user can arrange the records (containing one or more 
fields within the records) in ascending or descending se- 
quence for subsequent sequential processing. SORT can 
also create several different index files for accessing a file 
according to these indexes without reordering the data it- 
self. 

Comparing Files — A file differences command contrasts 
two files by automatically aligning matching text and op- 
tionally ignoring comments, empty records, trailing 
blanks, or multiple blanks. The output can be a file-by-file 
list of differences, an interleaved list of differences, a list 
with change bars, or a batch editor command input file. 
Backing Up Files and Volumes — The BACKUP utility en- 
ables a user to backup: 

® entire disk volumes 

® jndividual files 

® groups of files selected by date 


OPEN (“WEEKLY_PAYROLL_CHANGES”) 


Application System Programmer: 


Command Procedure: PAY_RUN.COM 


accepts one parameter (P1): Week Number 


$ ASSIGN WEEKLY_PAYROLL:‘P1’.WPY 


$ RUN APPLICATION 
Production Clerk: 
$ @PAY_RUN WEEKO9 


Payroll Group Operations Manager: 


$ ASSIGN/GROUP PAY_PACK:[PAYROLL.BACKUP] 


Local Operator: 
$ ASSIGN/SYSTEM DBA2: 


WEEKLY _PAYROLL_CHANGES 


WEEKLY_PAYROLL 


PAY PACK 


Figure 9-3 
Logical Naming 
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® groups of files selected by wildcard specifications 


When backing up disk volumes to other disk volumes, or 
restoring disk volumes from magnetic tape, BACKUP 
combines unused blocks on disks into contiguous areas. 


Verifying File Structures — The file-verification (VERIFY) 
utility checks the consistency and accuracy of the file 
structure on a Files-11 disk volume. It can also display the 
number of available blocks in a volume, locate files that 
could not otherwise be accessed, and list the names of 
files on the volume. 


Bad-Block Locator — The bad-block locator utility deter- 
mines the number and location of bad blocks on Files-11 
disk volumes and stores this information in the bad-block 
file on the volume so that the blocks can not be allocated. 
Running this utility before initializing a Files-11 volume is 
useful in ensuring a disk’s integrity. 


RMS Utilities — The record management services pro- 
cedures are complemented by a File Definition Language 
(FDL) and a number of utilities designed especially for 
RMS file creation and maintenance. With these utilities, 
users can create efficient files that use a minimum amount 
of system resources, decreasing I/O time. 


These utilities include: 

@e ANALYZE/RMS-FILE — Checks for structure errors in 
the data file and allows for interactive inspection of the 
data file structure. It can generate a report on the data 
file’s usage and can produce an FDL file that defines a 
data file. 


e CONVERT — Copies records from a source data file to a 
second data file, which can be of a different file or- 
ganization than the first. It can create a data file from the 
FDL file. 


e CONVERT/RECLAIM — Reclaims empty buckets in in- 
dexed files. 


e CREATE/FDL — Creates an empty data file from an FDL 
file. 


e EDIT/FDL — Creates and modifies FDL files and can 
create an empty data file. It also provides timing infor- 
mation and sophisticated defaults for various file attrib- 
utes. 


In addition, VAX-11 RMS supports a set of library routines 
that allows the user to invoke the CREATE/FDL and CON- 
VERT utilities from programs. 


VAX INFORMATION MANAGEMENT PRODUCTS 
The architecture of the VAX information management 
products was developed on the principle that no single ap- 
proach to information is appropriate for the typical user’s 
combination of application needs. The modular design 
makes it possible to apply the technology best-suited to 
filling the needs of an application. The components are a 
series of building blocks that fit into a well-defined soft- 
ware structure. 


The components of the architecture are arranged in layers 
above the operating system. Each layer has specific capa- 
bilities. The layered structure of the architecture makes it 
possible for components on one level to use the facilities 
of other components. 
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Figure 9-4 
Products of the Architecture 


On the top layer, the VAX languages and VAX-11 FMS 
(Forms Management System) provide a user interface for 
interactive and language-callable video forms. VAX-11 
DATATRIEVE supports English-like queries, hardcopy re- 
ports, and graphics. 


On the next level, the VAX-11 Common Data Dictionary 
(CDD) integrates the other components of the architec- 
ture. The CDD provides a facility for storing logical data 
definitions. 


Also on this level are the VAX-11 DATATRIEVE high-level 
and distributed-data-access facilities. High-level access 
provides the capability to access data without having to 
specify the means to access it, without specifying the file 
type, keys, etc. DATATRIEVE handles this by using defi- 
nitions in the CDD that contain information about the data 
characteristics and user needs. The high-level data access 
facility also supports a ‘relational join’ capability that can 
be used to dynamically link related records. Users do not 
have to determine in advance the records they want to link. 
Using a relational join, the high-level-access facility is ca- 
pable of making these associations dynamically. 


The distributed-data-access facility retrieves data from re- 
mote VAX-11 nodes running VAX-11 DATATRIEVE. The 
process is totally transparent to the user. A remote query 
looks just like a local query as far as the results of a DATA- 
TRIEVE request are concerned. 


The lowest level consists of two online multiuser data man- 
agement facilities: VAX-11 RMS (Record Management 
Services) and VAX-11 DBMS (Database Management Sys- 
tem). 


The VAX programming languages, which are a basic part 
of the VAX system architecture, are integrated into the in- 
formation architecture. Language support for high-level 
access and direct access to VAX-11 RMS files and VAX-11 
DBMS databases is provided through the VAX standard 
calling interface to VAX-11 DATATRIEVE. Programmers 
can concentrate on coding the procedural part of the ap- 
plication and can call DATATRIEVE to supply a high-level 
conditional value-based data access. The VAX languages 
are described in detail in Section 7. 


VAX-11 RMS 

VAX-11 RMS is a file access method with an extended syn- 
tax interface to all high-level languages. It supports se- 
quential, relative, and multikey indexed sequential file 
organizations, as well as concurrent file access with re- 
cord-level locking. VAX-11 RMS also supports transparent 
file access to and from remote DECnet systems. 


VAX-11 DATATRIEVE 

VAX-11 DATATRIEVE is a complete data management fa- 
cility that provides both interactive and program-callable 
access to data in RMS file organizations or in more com- 
plex interrelated DBMS database structures. It is a 
comprehensive query and report writer with full update ca- 
pabilities. It also includes an integrated graphics capability 
and forms support through FMS. 


VAX-11 Common Data Dictionary (CDD) 

The VAX-11 Common Data Dictionary is the keystone of 
the architecture. The CDD is prerequisite to the operation 
of VAX-11 DATATRIEVE and VAX-11 DBMS. VAX-11 DA- 
TATRIEVE statements refer to data definitions in the Com- 
mon Data Dictionary. The CDD is also used to store se- 
quences of VAX-11 DATATRIEVE statements as 
procedures that can be invoked interactively or from appli- 
cation programs, as well as to store database definitions 
that VAX-11 DBMS needs to create, access, and maintain 
databases. 


VAX-11 DBMS 

VAX-11 DBMS is a full-scale CODASYL-compliant data- 
base management system based on the March 1981 
Working Document of the ANSI Data Definition Commit- 
tee. It is a new implementation with many special ease-of- 
use and performance features. The VAX information archi- 
tecture allows DBMS data to be accessed directly from 
programming languages, through VAX-11 DATATRIEVE, 
or through special DBMS utilities. 


VAX-11 FMS 

VAX-11 FMS provides a forms management capability for 
programming languages and VAX-11 DATATRIEVE. It 
provides video form support for applications on VT100, 
VT125, and VT52 video terminals. FMS forms are defined 
interactively and then stored in a FMS forms library. At 
runtime, VAX-11 FMS works as a forms management soft- 
ware front end. It passes data between user programs and 
a video terminal on a per-field or per-form basis. 


The process works exactly the same way when FMS forms 
are used with VAX-11 DATATRIEVE. If a form name is 
used as part of a DATATRIEVE definition, the VAX-11 DA- 
TATRIEVE facility will automatically use the form to collect, 
display, or modify the associated data. 


The following sections describe the information manage- 
ment products in more detail. 


RECORD MANAGEMENT SERVICES (RMS) 

The record management services (RMS) are a set of sys- 
tem procedures that provide efficient and flexible facilities 
for data storage, retrieval, and modification. When writing 
programs, the user can select processing methods from 
among the RMS file organizations and accessing tech- 
niques. The following sections discuss RMS: 
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® file organizations 

® file attributes 

© program operations 
® runtime environment 


The manner in which RMS builds a file is called its or- 
ganization. RMS provides three file organizations: 


® sequential 
® relative 
® indexed 


All three file organizations are available in both compatibil- 
ity mode (using RMS-11) and in native mode (using VAX- 
11 RMS). 

The organization of a file establishes the techniques one 
can use to retrieve and store data in the file. These 
techniques are known as record access modes. The re- 
cord access modes that RMS supports are: 

® sequential 

® random 

® Record’s File Address (RFA) 


An application program or a RMS utility can be used when 
creating a RMS file to specify the organization and charac- 
teristics of the file. Among the attributes specified are: 

® storage medium 

® filename and protection specifications 

® record format and size 

® file allocation information 


After RMS creates a file according to the specified attrib- 
utes, application programs can store, retrieve, and modify 
data. These program operations take place on the logical 
records in a file or on the blocks of the file. 


RMS FILE ORGANIZATIONS 

A file is a collection of related information. For example, a 
file might contain a company’s personnel information 
(employee names, addresses, job titles). Within this file, 
the information is divided into records. All the information 
on a single employee might constitute a single record. 
Each record in the personnel file would be subdivided into 
discrete pieces of information known as fields. The user 
defines the number, locations within the record, and logi- 
cal interpretations of these fields. 


The user can completely control the grouping of fields into 
records and records into files. The relationship among 
fields and records is embedded in the logic of the pro- 
grams. RMS does not know the logical relationships that 
exist within the information in the files. 


RMS ensures that every record written into a file can sub- 
sequently be retrieved and passed to a requesting pro- 
gram as a single logical unit of data. The structure, or 
organization, of a file establishes the manner in which 
RMS stores and retrieves records. The way a program re- 
quests the storage or retrieval of records is known as the 
record access mode. The organization of a file determines 
which record access modes can be used. 


Sequential File Organization 

In sequential file organization, records appear in consecu- 
tive sequence. The order in which records appear is the 
order in which the records were originally written to the file 


END OF FILE 


RECORD RECORD RECORD RECORD RECORD RECORD - - RECORD RECORD 


Figure 9-5 
Sequential File Organization 


by an application program or RMS utility. Sequential or- 
ganization is the only file organization permitted for 
magnetic tape and unit record devices. Most VAX/VMS 
system utilities that deal with files deal with sequentially or- 
ganized files. All system editors and language processors, 
for instance, operate on sequentially organized files. Fig- 
ure 9-5 illustrates sequential file organization. 


Relative File Organization 

When relative organization is selected, RMS structures a 
file as a series of fixed-size record cells. Cell size is based 
on the maximum length permitted for a record in the file. 
These cells are numbered from 1 (the first) to n (the last). A 
cell’s number represents its location relative to the begin- 
ning of the file. 


Each cell in a relative file can contain a single record. 
There is no requirement, however, that every cell contain a 
record. Empty cells can be interspersed among cells con- 
taining records. Figure 9-6 illustrates a relative file or- 
ganization. 


Since cell numbers in a relative file are unique, they can be 
used to identify both a cell and the record (if any) occupy- 
ing that cell. Thus, record number 1 occupies the first cell 
in the file, record number 17 occupies the seventeenth 
cell, and so forth. When a cell number is used to identify a 
record, it is also known as a relative record number. 


Indexed File Organization 

The location of records in indexed file organization is 
transparent to the program. RMS completely controls the 
placement of records in an indexed file. The presence of 
keys in the records of the file governs this placement. 


A key is a field that's present in every record of an indexed 
file. The location and length of this field are identical in all 
records. When creating an indexed file, the user decides 
which field or fields in the file’s records are to be a key. Se- 
lecting such fields indicates to RMS that the contents (i.e., 
key value) of those fields in any particular record written to 
the file can be used by a program to identify that record for 
subsequent retrieval. 
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At least one key must be defined for an indexed file — the 
primary key. Optionally, additional keys or alternate keys 
can be defined. An alternate key value can also be used as 
a means of identifying a record for retrieval. 


As programs write records into an indexed file, RMS 
builds a tree-structured table known as an index. An index 
consists of a series of entries, each of which contain a key 
value copied from a record that a program wrote into the 
file. Stored with each key value is a pointer to the location 
in the file of the record from which the value was copied. 
RMS builds and maintains a separate index for each key 
defined for the file. Each index is stored in the file. Thus, 
every indexed file contains at least one index — the pri- 
mary key index. Figure 9-7 illustrates an indexed file or- 
ganization with a primary key. When alternate keys are de- 
fined, RMS builds and stores an additional index for each 
alternate key. 


RMS RECORD ACCESS MODES 

The methods of retrieving and storing records in a file are 
called record access modes. A different record access 
mode can be used to process records within the file each 
time it is opened. A program can also change record ac- 
cess mode during the processing of a file. RMS permits 
only certain combinations of file organization and record 
access mode. Table 9-1 lists these combinations. 


Sequential Record Access Mode 

Sequential record access mode can be used to access all 
RMS files and all record-oriented devices, including mail- 
boxes. Sequential record access means that records are 
retrieved or written in the sequence established by the or- 
ganization of the file. 


Sequential Access to Sequential Files — When using se- 
quential record access mode in a sequentially organized 
file, physical arrangement establishes the order in which 
records are retrieved. To read a particular record in a file, 
say the fifteenth record, a program must open the file and 
access the first fourteen records before it can access the 
desired record. Thus, each record in a sequential file can 
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Figure 9-6 
Relative File Organization 
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be retrieved only by first accessing all records that 
physically precede it. Similarly, once a program has re- 
trieved the fifteenth record, it can read all the remaining 
records (from the sixteenth on) in physical sequence. It 
cannot, however, read any preceding record without first 
closing, reopening the file, and beginning again with the 
first record. 


Sequential Record Access to Relative Files — During the 
sequential access of records in the relative file organiza- 
tion, the contents of the record cells in the file establish the 
order in which a program processes records. RMS recog- 
nizes whether successively numbered record cells are 
empty or contain records. 


When a program issues read requests in sequential record 
access mode for a relative file, RMS ignores empty record 
cells and searches successive cells for the first one con- 
taining a record. When a program adds new records in se- 
quential record access mode to a relative file, RMS places 
a record in the cell whose relative number is one higher 
than the relative number of the previous request — as long 
as that cell does not already contain a record. RMS allows 
a program to write new records only into empty cells in the 
file. 


Sequential Record Access to Indexed Files — A program 
can use the sequential record access mode to retrieve re- 
cords from an indexed file in the order represented by any 
index. The entries in an index are arranged in ascending 
order by key values. If more than one key is defined for the 
file, each separate index associated with a key represents 
a different logical ordering of the records in the file. 


When reading records in sequential record access mode 
from an indexed file, a program initially specifies a key 
(primary key, first alternate key, second alternate key, etc.) 
to RMS. Thereafter, RMS uses the index associated with 
that specified key to retrieve records in the sequence rep- 
resented by the entries in the index. Each successive rec- 
ord RMS returns in response to a read request contains a 
value in the specified key field that is equal to or greater 
than that of the previous record returned. 


When writing records to an indexed file, RMS uses the def- 
inition of the primary key field to place the record in the 
file. 


Random Record Access Mode 

In random record access mode, the program establishes 
the order in which records are processed. Each program 
request for access to a record operates independently of 
the previous record accessed. Each request in random 
record access mode identifies the particular record of in- 
terest. Successive requests in random mode can identify 
and access records anywhere in the file. 


Random Record Access to Sequential Files — Native 
programs can access sequential files ondisk using relative 
record number to randomly locate a record, and provided 
that the records are in fixed-length record format. 


Random Record Access to Relative Files — Native pro- 
grams can read or write records in a relative file by speci- 
fying the relative record number. RMS interprets each 
number as the corresponding cell in the file. A program 
can read records at random by successively requesting, 
for example, record number 47, record number 11, record 
number 31, and so forth. If no record exists in a specified 
cell, RMS notifies the requesting program. Similarly, a pro- 
gram can store records in a relative file by identifying the 
cell in the file that a record is to occupy. If a program at- 
tempts to write a new record in a cell already containing a 
record, RMS notifies the program. 


Random Record Access to Indexed Files — For indexed 
files, a key value, rather than a relative record number, 
identifies the record. Each program read request in ran- 
dom record access mode specifies a key value and the in- 
dex (primary index, first alternate index, second alternate 
index, etc.) that RMS must search. When RMS finds the 
key value in the specified index, it reads the record that the 
index entry points to and passes the record to the user 
program. 


Record’s File Address (RFA) Record Access Mode 
Record’s File Address (RFA) record access mode can be 
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Figure 9-7 
Indexed File Organization 
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used to retrieve records in any file organization, as long as 
the file resides on a disk volume. Like random record ac- 
cess mode, RFA record access allows a specific record to 
be identified for retrieval, using the record’s unique ad- 
dress. The actual format of this address depends on the 
organization of the file. 


After every successful read or write operation, RMS re- 
turns the RFA of the subject record to the program. The 
program can then save this RFA to use again, to retrieve 
the same record. It is not required that this RFA be used 
only during the current execution of the program. RFAs 
can be saved and used at any subsequent time. 


Dynamic Access 

Dynamic access is not strictly an access mode. It is the 
ability to switch from one record access mode to another 
while processing a file. For example, a program can ac- 
cess a record randomly, then switch to sequential record 
access mode for processing subsequent records. There is 
no limitation on the number of times such switching can 
occur. The only limitation is that the file organization must 
support the record access mode selected. 


FILE AND RECORD ATTRIBUTES 

When creating an RMS file, a program or user defines its 
logical and physical characteristics, or attributes. These 
characteristics are defined by source-language state- 
ments in an application program, in the FDL language, or 
by an RMS utility. The program or user assigns the file a 
name, the owner’s User Identification Code, and a protec- 
tion code and then selects the file organization. The pro- 
gram or user also defines or selects other attributes, 
including: 

e device 

e file size 

e file location 

e record format and size 


e keys (for indexed files only) 


Selection of device is related to the organization of the file. 
Sequential files can be created on Files-11 disk volumes or 
ANSI magnetic-tape volumes. Sequential files can also be 
read from mailboxes, terminals, and cardreaders, and 
written to mailboxes, terminals, and lineprinters. Relative 
and indexed files can be created on Files-11 disk volumes. 


The logical limit on file size is ga1— 1 blocks, with a more 
realistic limit being the volume set on which a file can 
reside. When creating an RMS file on a disk volume, the 
user can specify an initial allocation size. If no file size is 
given, RMS allocates the minimum amount of storage 
needed to contain the defined attributes of the file. The ini- 
tial size can be extended dynamically. The user can let 
RMS locate the file, or the user can allocate the file to spe- 
cific locations on the disk, to optimize disk access time. 
The file’s starting location can be specified, optionally, us- 
ing a volume-relative block number or a physical cylinder 
address. 


When creating a file on a magnetic-tape volume, a user or 
program does not specify an initial allocation size. The 
blocks are simply written one after another down the tape, 
beginning after the last file, if any, written on the tape. 
Once a tape file has been created, another file can replace 
it or be appended to it, but all subsequent files on the tape, 
if any, are lost. 


Record Formats 

The user provides the format for the records the file will 
contain. The specified format establishes how each record 
appears in the file. 


Fixed-length record format refers to records of a file that 
are all equal in size. Each record occupies an identical am- 
ount of space in the file. All file organizations support 
fixed-length record format. 


Variable-length record format records can be either equal 
or unequal in length. All file organizations support vari- 
able-length record format. RMS prefixes a count field to 
each variable-length record it writes. The count field de- 
scribes the length (in bytes) of the record. RMS removes 
the count field before it passes a record to the program. 

RMS produces two types of count fields, depending on the 

storage medium on which the file resides: 

e Variable-length records in files on Files-11 disk volumes 
have a 2-byte binary count field preceding the data field 
portion of each record. The specified size excludes the 
count field. 


e Variable-length records on ANSI magnetic tapes have 4- 
character decimal count fields preceding the data por- 
tion of each record. The specified size includes the 
count field. In the context of ANSI tapes, this record for- 
mat is known as D format. 


Table 9-1 
Record Access Modes and File Organizations 


File Organization 


Sequential 
Sequential Yes 
Relative’ Yes 
Indexed! Yes 


1 Disk files only. 


2 Fixed-length record format (disk files only). 


Record Access Mode 


Random RFA 
Record # Key Value 
Yes? No Yes! 
Yes No Yes 
No Yes Yes 


Variable-with-fixed-length-control records consist of two 
distinct parts, the fixed-length-control area and a variable- 
length data record. Although stored together, the two parts 
are returned to the program separately when the record is 
read. The size of the fixed-length-control area is identical 
for all records of the file. The contents of the fixed-length- 
control area are completely under the control of the pro- 
gram and can be used for any purpose. For example, 
fixed-length-control areas can be used to store the identi- 
fier (relative record number or RFA) of related records. In- 
dexed file organization does not support this option. 


A stream record format is a record format wherein records 
in a file are delimited by the occurrence of special charac- 
ter sequences called terminators. Terminators are parts of 
the records they delimit. The data in a stream format file 
are interpreted as a continuous sequence of bytes without 
control information, such as record counts, or system- 
supplied boundaries. Only the sequential file organization 
supports stream format. 


Key Definitions for Indexed Files 

To define a key for an indexed file, the user specifies the 
position and length of particular data fields within the re- 
cords. At least one key — the primary key — must be de- 
fined for an indexed file. Additionally, up to 254 alternate 
keys can be defined. In general, most files have two or 
three keys. Because indexes require storage space, and 
because RMS updates indexes as records are added or 
modified, no more than six to eight keys should be de- 
fined, if storage space or access time is important. 


Each primary and alternate key represents from 1 to 255 
bytes in each record of the file. RMS permits six key field 
data types. 

e string 

signed 15-bit integer 

unsigned 16-bit binary 

signed 31-bit integer 

unsigned 32-bit binary 

packed-decimal 


The string key field can be composed of simple or seg- 
mented keys. A simple key is a single contiguous string of 
characters in the record — in other words, a single field. A 
segmented key, however, can consist of from two to eight 
fields within records. These fields need not be contiguous. 
When processing records that contain segmented keys, 
RMS treats each separate field (Segment) as a logically 
contiguous character string. The integer, binary, and 
packed-decimal data types can only be simple keys. 


When defining keys at file creation time, two characteris- 
tics for each key can be specified: 

e duplicate key values are or are not allowed 

e key value can or cannot change 


When duplicate key values are allowed, more than one re- 
cord can have the same value in a given key. For example, 
the creator of a personnel file could define the depart- 
ment-name field as an alternate key. As programs wrote 
records into the file, the alternate index for the department 
name key field would contain multiple entries for each key 
value (e.g., PAYROLL, SALES, ADMINISTRATION), since 
departments are composed of more than one employee. 
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When such duplication occurs, RMS stores the records so 
that they can be retrieved in first-in/first-out (FIFO) order. 


If key values can change, records can be read and then 
written back into the file with a modified key value. This 
specification would allow a program to access a record in 
the personnel file and change the contents of a depart- 
ment-name field, to reflect the transfer of an employee 
from one department to another. This characteristic can 
be specified only for alternate keys. 


Figures 9-8 and 9-9 show excerpts from a COBOL pro- 
gram that operates upon an indexed customer information 
file via the dynamic access method. The program 
searches through the file and generates various reports, 
based upon the customer’s financial status and additional 
input typed in by the user at the terminal. In Figure 9-8, the 
program describes the organization of the file and speci- 
fies the access method to be used. In Figure 9-9, the pro- 
gram searches for the first nonzero customer number. Us- 
ing the “approximate key” match facility (greater than), the 
program searches for the first nonzero customer. When 
RMS has located the first nonzero customer number, the 
program changes access method, and the file is read se- 
quentially. 
INPUT-OUTPUT SECTION. 
FILE-CONTROL. 
SELECT CUSTOMER-FILE 

ASSIGN TO "CUSTOM.DAT"” 

ORGANIZATION IS INDEXED 

ACCESS MODE IS DYNAMIC 

RECORD KEY IS CUST-CUSTOMER-NUMBER 


ALTERNATE RECORD IS KEY IS CUST-CUSTOMER-NAME 
FILE STATUS IS CUSTOMER-FILE-STATUS. 


Figure 9-8 
ISAM File Description 


OPEN INPUT CUSTOMER-FILE. 
MOVE "000000" TO CUST-CUST-NUMBER. 
START CUSTOMER-FILE. 
KEY IS > CUST-CUST-NUMBER. 
OPEN OUTPUT STATEMENT-REPORT. 
MAINLINE SECTION. 
SBEGIN. 
READ CUSTOMER-FILE NEXT 
AT END 
GO TO END-PROCESS. 
ADD 1 TO RECORD-COUNT. 


Figure 9-9 
Dynamic Access Processing 


PROGRAM OPERATIONS ON RMS FILES 

After RMS has created a file according to the user’s de- 
scription of file characteristics, a program can access the 
file and store and retrieve data. 


When a program accesses the file as a logical structure 
(i.e., a sequential, relative, or indexed file), it uses record 
I/O operations such as add, update, and delete record. 
The organization of the file determines the types of record 
operations permitted. 


If the record-accessing capabilities of RMS are not used, 
programs can access the file as an array of virtual blocks. 
To process a file at this level, programs use a type of ac- 
cess known as block I/O. 


File Processing 

At the file level — that is — independent of record process- 
ing, a program can: 

® create a file 

® open an existing file 

® modify file attributes 

® extend a file 

® close the file 

@ delete a file 


Once a program has opened a file for the first time, it has 
access to the unique internal ID for the file. If the program 
intends to open the file subsequently, it can use that inter- 
nal ID to open the file and avoid any directory search. 


Record I/O Processing 

The organization of a file, which is defined when the file is 
created, determines the types of operations that the 
program can perform on records. Depending on file or- 
ganization, RMS permits a program to perform the follow- 
ing record operations: 

e Read a record. RMS returns an existing record within 

the file to the program. 


e Write a record. RMS adds a new record that the pro- 
gram constructs to the file. The new record cannot re- 
place an already existing record. 


e Find a record. RMS locates an existing record in the file. 
It does not return the record to the program, but estab- 
lishes a new current position in the file. 


® Delete a record. RMS removes an existing record from 
the file. The delete record operation is not valid for the 
sequential file organization. 

e Update a record. The program modifies the contents of 
a record in the file. RMS writes the modified record into 
the file, replacing the old record. The update record 
operation is not valid for sequential file organizations, 
except for sequentially organized disk files. 


Sequential File Record [/O — |In a sequential file organiza- 
tion, a program can read existing records from the file us- 
ing sequential, RFA, or — if the file contains fixed-length 
records — random record access mode. New records can 
be added only to the end of the file and only through the 
use of sequential or random record access mode. 


The find operation is supported in both sequential and 
RFA record access modes. In sequential record access 
mode the program can use a find operation to skip re- 
cords. In RFA record access mode, the program can use 
the find operation to establish a random starting point in 
the file for sequential read operations. 


The sequential file organization does not support the de- 
lete operation, since the structure of the file requires that 
records be adjacent in and across virtual blocks. A pro- 
gram can, however, update existing records in sequential 
disk files, as long as the modification of a record does not 
alter its size. 


Relative File Record I/O — Relative file organization 
permits programs greater flexibility in performing record 
operations than does sequential organization. A program 
can read existing records from the file using sequential, 
random, or RFA record access mode. 


New records can be sequentially or randomly written, as 
long as the intended record cell does not already contain a 
record. Similarly, any record access mode can be used to 
perform a find operation. After a record has been found or 
read, RMS permits the delete operation. Once a record 
has been deleted, the record cell is available for a new re- 
cord. A program can also update records in the file. If the 
format of the records is variable, update operations can 
modify record length up to the maximum size specified 
when the file was created. 


Indexed File Record I/O — \|Indexed file organization pro- 
vides the greatest flexibility in performing record opera- 
tions. A program can read existing records from the file in 
sequential, RFA, or random record access mode. When 
reading records in random record access mode, the pro- 
gram can choose one of four types of matches that RMS 
performs, using the program-provided key value. The four 
types of matches are: 


® exact key match 

® approximate key match 

® generic key match 

® approximate and generic key match 


Exact key match requires that the contents of the key in the 
record retrieved precisely match the key value specified in 
the program read operation. 


The approximate match facility allows the program to se- 
lect either of the following relationships between the key of 
the record retrieved and the key value specified by the 
program: 


® equal to or greater than 
® greater than 


The advantage of this kind of match is that, if the 
requested key value does not exist in any record of the file, 
RMS returns the record that contains the next higher key 
value. This allows the program to retrieve records, without 
knowing an exact key value. 


Generic key match means that the program need specify 
only an initial portion of the key value. RMS returns to the 
program the first occurrence of a record whose key con- 
tains a value beginning with those characters. This allows 
the program to retrieve a class of records — for example, 
all employee records in the personnel file with a name field 
beginning with M. 

Approximate and generic match means that the program 
specifies only an initial portion of the key value, as does 
generic match. Additionally, a program specifies that the 
key data field of the record retrieved must be either: 


® equal to or greater than the program-supplied 
value 
® greater than the program-supplied value 


RMS also allows any number of new records to be written 
into an indexed file. It rejects a write operation only if the 


value contained in a key of the record violates a user-de- 
fined key characteristic (e.g., duplicate key values not per- 
mitted). 


The find operation, similar to the read operation, can be 
performed in sequential, RFA, or random record access 
mode. When finding records in random record access 
mode, the program can specify any one of the four types of 
key matches provided for read operations. 


In addition to read, write, and find operations, the program 
can delete any record in an indexed file and update any 
record. The only restriction RMS applies during an update 
operation is that the contents of the modified record must 
not violate any user-defined key characteristic (e.g., key 
values cannot change, and duplicate key values are not 
permitted). 


Block I/O Processing 

Block I/O allows a program to bypass the record-process- 
ing capabilities of RMS entirely. Rather than performing 
record operations through the use of supported record ac- 
cess modes, a program can process a file as a structure 
consisting solely of blocks. 


Using block I/O, a program reads or writes blocks by iden- 
tifying a starting virtual block number in the file and a 
transfer length. Regardless of the organization of the file, 
RMS accesses the identified block or blocks, on behalf of 
the program. 


Since RMS files, particularly relative and indexed files, 
contain internal information meaningful only to RMS itself, 
DIGITAL does not recommend that a file be modified by 
using block I/O. The presence of the block I/O facility, 
however, does permit user-created record formats on a 
Files-11 disk volume or an ANSI magnetic tape volume. 


RMS RUNTIME ENVIRONMENT 

The environment within which a program processes RMS 
files at runtime has two levels, the file-processing level and 
the record-processing level. 


At the file-processing level, RMS and the operating system 
provide an environment that permits concurrently execut- 
ing programs to share access to the same file. RMS ascer- 
tains the amount of sharing permissible from information 
provided by the programs themselves. Additionally, at the 
file-processing level, RMS provides facilities that allow 
programs to exercise as little or as much control over 
buffer space requirements for file processing as desired. 


At the record-processing level, RMS allows programs to 
access records in a file through one or more record access 
streams. Each record access stream represents an inde- 
pendent and simultaneously active series of record opera- 
tions directed toward the file. Within each stream, pro- 
grams can perform record operations synchronously or 
asynchronously. That is, RMS allows programs to choose 
between receiving control only after a record operation re- 
quest has been satisfied (synchronous operation) or re- 
ceiving control before the request has been satisfied 
(asynchronous operation). 


For both synchronous and asynchronous record opera- 
tions, RMS provides two record transfer modes — move 
mode and locate mode. Move mode causes RMS to copy a 
record to/from an I/O buffer from/to a program-provided 


location. Locate mode allows programs to process re- 
trieved records directly in an I/O buffer. 


Runtime File Processing 

VAX-11 RMS allows executing programs to share files, 
rather than require them to process files serially. The man- 
ner in which a file can be shared depends on the organiza- 
tion of the file. Program-provided information further es- 
tablishes the degree of sharing of a particular file. 


File Organization and Sharing — With the exception of 
magnetic-tape files, which cannot be shared, an RMS file 
can be shared by any number of programs that are read- 
ing, but not writing, the file. Relative and indexed files and 
sequential disk files with 512 bytes fixed-length records 
can be shared by multiple readers and multiple writers. 
Other sequential disk files can be shared by multiple read- 
ers and multiple writers, but the accessing programs are 
responsible for any record locking required to handle mul- 
tiple readers and writers properly. 


Program Sharing Information — A program specifies what 
kind of sharing actually occurs at runtime. The user con- 
trols the sharing of a file through information the program 
provides RMS when it opens the file. First, a program must 
declare what operations (e.g., read, write, delete, update) 
it intends to perform on the file. Second, a program must 
specify whether other programs can read the file — or 
both read and write the file — concurrently with this pro- 
gram. 


These two types of information allow RMS to determine if 
multiple user programs can access a file at the same time. 
Whenever a program’s sharing information is compatible 
with the corresponding information another program pro- 
vides, both programs can access the file concurrently. 


Buffer Handling — To aprogram, record processing under 
RMS appears as the direct movement of records between 
a file and the program itself. Transparently to the program, 
however, RMS reads or writes the blocks of a file into or 
from internal memory areas known as I/O buffers. Re- 
cords within these buffers are then made available to the 
program. Users can control the number and size of 
buffers. For sequential record access, users can choose 
an optional |/O read-ahead and write-behind buffer man- 
agement. For shared files, users may choose an optional 
shared memory section to serve as a global cache of buff- 
ers. For magnetic-tape file access, they can control the 
number of buffers for multiple buffering. For sequential 
disk files, users can specify the number of blocks that are 
to be transferred whenever RMS performs an I/O opera- 
tion. 


Runtime Record Processing 

After opening a file, a program can access records in the 
file through the RMS record-processing environment. This 
environment provides three facilities: 

@® record access streams 

e synchronous or asynchronous record operations 


® record transfer modes 


Record Access Streams — I|In the record-processing envi- 
ronment, a program accesses records in a file through a 
record access stream. A record access stream is a serial 
sequence of record operation requests. For example, a 


program can issue a read request for a particular record, 
receive the record from RMS, modify the contents of the 
record, and then issue an update request that causes RMS 
to write the record back into the file. The sequence of read 
and update record operation requests can then be per- 
formed for a different record, or other record operations 
can be performed, again in a serial fashion. Thus, within a 
record access stream, there is, at most, one record being 
processed at any time. 


For relative and indexed files, RMS permits a program to 
establish multiple record access streams for record oper- 
ations to the same file. The presence of such multiple rec- 
ord access streams allows programs to process in parallel 
more than one record of a file. Each stream represents an 
independent and concurrently active sequence of record 
operations. 


As an example of multiple record access streams, a 
program could open an indexed file and establish two rec- 
ord access streams to the file. The program could use one 
record access stream to access records in the file in ran- 
dom access mode through the primary index. At the same 
time, the program could use the second record access 
stream to access records sequentially in the order speci- 
fied by an alternate index. 


Synchronous and Asynchronous Record Operations — 
Within each record access stream, a program can perform 
any record operation either synchronously or asynchro- 
nously. When a record operation is performed synchro- 
nously, RMS returns control to a program only after the re- 
cord operation request has been satisfied (e.g., a record 
has been read and passed on to the program). 


If the programming language allows asynchronous 
processing, RMS can return control to a program before 
the record operation request has been satisfied. A pro- 
gram can use the time required for the physical transfer to 
perform other computations. A program cannot, however, 
issue a second record operation through the same stream 
until the first record operation has completed. To ascertain 
when a record operation has actually been performed, a 
program can specify completion routines or issue a wait 
request and regain control when the record operation is 
complete. 


Record Transfer Modes — A program can use either of 
two record transfer modes to gain access to each record in 
memory: 

@® move mode 


e locate mode 


Move mode means that the individual records are copied 
between the I/O buffer and a program. For read opera- 
tions, RMS reads a block into an I/O buffer, finds the de- 
sired record within the buffer, and moves the record to a 
program-specified location in its workspace. For write op- 
erations, the program builds or modifies a record in its 
own work space and RMS moves the record to an I/O 
buffer. RMS supports move mode record operations for all 
file organizations. 


Locate mode enables programs to read records directly in 
an I/O buffer. Locate mode reduces the amount of data 
movement, thereby saving processing time. RMS provides 
the program with the address and size of the record in the 


1/O buffer. RMS supports locate mode record transfers on 
all file organizations for read operations only. 


RMS Record Locking 
VAX-11 RMS provides a record-locking capability for files 
that use the relative and indexed organization. In addition, 
RMS record locking is supported for sequential files with 
512-byte fixed-length records. This provides control over 
operation when the file is being accessed simultaneously 
by more than one program and/or more than one stream 
in a program. Record locking makes certain that, when a 
program is adding, deleting, or modifying a record on a 
given stream, another program or stream is not allowed 
access to the same record or record cell. RMS-11 execut- 
ing in compatibility mode does not support record locking 
and file sharing. There are two varieties of record locking 
and unlocking: 

e Automatic Record Locking — The lock occurs on every 
execution of a $FIND or $GET macro instruction. The 
lock is released when the next record is accessed, the 
current record is updated or deleted, the record stream 
is disconnected, or the file is closed. The $FREE macro 
instruction explicitly unlocks all records previously 
locked for a particular record stream. The $RELEASE 
macro instruction explicitly unlocks a specified record in 
a record stream. 


Manual Record Locking — |In manual record locking, 
varying degrees of locking can be specified by setting 
bits in the record-processing options field (ROP) of the 
RAB. The ULK bit specifies manual (as opposed to au- 
tomatic) locking and unlocking. Locking is then con- 
trolled for $GET, $FIND, or $PUT macro instruction ona 
per-operation basis and unloading takes place explicitly 
via a $FREE or $RELEASE macro instruction. Additional 
ROP bits control the exact form of locking. The NLK bit 
specifies that the record accessed is not to be locked. 
The RLK bit specifies that a record may be accessible 
for read purposes but may not otherwise be accessed. 
The REA bit specifies that record to be locked for read 
access. The RLL bit specifies that the record should be 
accessed regardless of whether it is locked or not. 


VAX-11 DATATRIEVE 

VAX-11 DATATRIEVE is a comprehensive information 
management tool that can be used interactively from a ter- 
minal or called from an application program. The system is 
designed for relatively novice computer users as well as 
experienced users. 


Everyday use of DATATRIEVE requires no programming 
skills. It allows direct, easy, and fast access to data con- 
tained in VAX-11 RMS (Record Management System) files 
and VAX-11 DBMS databases. VAX-11 DATATRIEVE fea- 
tures integrated editing and report-writing and graphic- 
output facilities and supports the forms management fa- 
cility of FMS. VAX-11 DATATRIEVE also provides exten- 
sive online help facilities. 


DATATRIEVE Inquiry Facility 

DATATRIEVE accepts English-like commands from the 
user and reacts by updating or extracting data from the 
specified VAX-11 RMS file and VAX-11 DBMS structure. In 
cases where certain sequences of commands need to be 


issued on a recurring basis, DATATRIEVE provides a fea- 
ture that permits the definition and use of procedures. A 
procedure is a group of DATATRIEVE statements and 
commands identifiable (callable) by a unique procedure 
name. At any time during the interactive session, this 
group of DATATRIEVE statements and commands can be 
invoked simply by calling the procedure name. 


VAX-11 DATATRIEVE provides a subset capability to allow 
novice users to learn about DATATRIEVE as well as to im- 
mediately be able to do meaningful work. Called ‘Guide 
Mode’, this facility provides explicit help at all decision 
points. 


The major commands and statements are: 
e CROSS — allows multiple files to be accessed, using a 
common field. 


DECLARE — defines global and local variables to be 
used within a DATATRIEVE query. 


DEFINE — provides a consistent mechanism for creat- 
ing domain, record, table, and view definitions in the 
VAX-11 Common Data Dictionary. 


DROP — allows records to be deleted from a collection 
(subset) only, while not modifying the actual data file. 


EDIT — invokes an editor that inserts, modifies, or de- 
letes text from procedures defined in the VAX-11 Com- 
mon Data Dictionary, or from the last line entered in an 
interactive session. 


ERASE — deletes one or more records corresponding 
to the appropriate domain. 


FIND — establishes a collection (subset) of records con- 
tained in either a domain or a previously established 
collection based on a Boolean expression. 


FOR — executes a subsequent command once for each 
record in the record collection, providing a simple loop- 
ing facility. 

HELP — provides a summary of each DATATRIEVE 
command as well as examples of the syntax. 


MODIFY — alters the values of one or more fields for ei- 
ther the selected record or all records in a collection. 
Replacement values are prompted for by name, or 
shown on a predefined form. 


PLOT — allows a collection of records to be dis- 
played/printed in graphic representation. 


PRINT — prints one or more fields of one or more re- 
cords. Output can optionally be directed to a lineprinter 
or disk file. Format control can be specified. A column 
header is generated automatically. 


READY — identifies a domain for processing and con- 
trols the access mode to the appropriate file. 


SELECT — identifies a single record in a collection for 
subsequent individual processing. 

SORT — reorders a collection of records in either the 
ascending or descending sequence of the contents of 
one or more fields in the records. 

STORE — creates a new record. The value for each field 
contained in the record is prompted for by name or indi- 
cated on a predefined form. 


In addition to the simple data manipulation commands, 
several more complex commands are available for the ad- 
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vanced user. Such commands as REPEAT, BEGIN-END, 
and IF-THEN-ELSE can be used to combine two or more 
DATATRIEVE commands into a single compound com- 
mand. These, in turn, can be stored in the Common Data 
Dictionary as procedures for invocation by less-experi- 
enced users. With these procedures, users also have the 
ability to program applications. 


DATATRIEVE provides a full set of arithmetic operators 
(i.e., addition, subtraction, multiplication, division, and ne- 
gation), a set of statistical operators (i.e., total, average, 
maximum, minimum, count, etc.), and automatic conver- 
sion between data types used in the FORTRAN, COBOL, 
Pascal, PL/I, DIBOL, and BASIC languages. 


Common Data Dictionary 

All data definitions are stored and retrieved from the VAX- 
11 Common Data Dictionary. VAX-11 DATATRIEVE in- 
cludes commands to store, examine, modify, and delete 
definitions in the CDD, but it can also use definitions 
stored there by the VAX-11 DBMS DDLs (Data Definition 
Languages) and the CDDL (Common Data Definition Lan- 
guage). The CDD is required in order to run VAX-11 
DATATRIEVE. 


Users can define sequences of VAX-11 DATATRIEVE 
commands and statements with the DEFINE PROCEDURE 
command and store them in the CDD for later use. PRO- 
CEDURES can be invoked to run by themselves or can be 
embedded in other sequences of commands and state- 
ments. PROCEDURES can be invoked by interactive users 
or application programs. 


VAX-11 DATATRIEVE tables can be defined to reside in 
the VAX-11 Common Data Dictionary or exist as DATA- 
TRIEVE domains. Tables can be used as a must-match list 
for field validation or for argument-function-type conver- 
sions. 


Data Definition 

Implementing a VAX-11 DATATRIEVE application is a two- 
phase process. In the first phase, the appropriate state- 
ments are used to define all data that will be accessed by 
the application. This needs to be done only once to 
establish a foundation on which to build the application. In 
the second phase, VAX-11 DATATRIEVE statements are 
used to process the data associated with these definitions. 


VAX-11 DATATRIEVE manipulates records, fields, files, 
domains, and collections of information. Records are 
groups of related items of data that are treated as a unit. 
Each individual piece of data in a record is referred to as a 
field. The term files refers to the logically related groups of 
data that are kept by RMS. 


Domains represent relationships between actual physical 
data and descriptions of data. A VAX-11 DATATRIEVE do- 
main definition consists of adomain name, the name of the 
VAX-11 RMS file, the name of the record format descrip- 
tion, or other kinds of domain definitions. A record format 
description defines the fields within the record, assigning 
each field a name and specifying its length, data type, and 
other vital parameters. All VAX-11 DATATRIEVE domain 
definitions and record format descriptions are contained 
in the VAX-11 Common Data Dictionary. 


Domains can span multiple VAX-11 RMS files or VAX-11 
DBMS record types and can include the name of an asso- 
ciated VAX-11 FMS form or VAX-11 DATATRIEVE tables. 
Domains can also be defined as remote. This means that 
the actual data definition and the data exist on a remote 
VAX-11 DATATRIEVE node and can be accessed through 
DECnet-VAX communications software using, the distrib- 
uted data access facility. 


VAX-11 DATATRIEVE allows domains to be defined that 
can subset the fields of a record and can span multiple 
VAX-11 RMS or VAX-11 DBMS record types. These are 
called view domains because they provide a user’s logical 
view of the data. Once view domains have been esta- 
blished, they can be used in much the same ways as sim- 
ple domains. This facility is basic to high-level data access. 
It makes it possible for a single statement to retrieve a set 
of related records. View domains can also be used with 
VAX-11 RMS files for domains containing records related 
in a hierarchical fashion. 


Data Management 

Data management involves creating and maintaining data 
in a current and correct state by adding, eliminating, and 
modifying records. The STORE, ERASE, and MODIFY 
statements are used to perform these relatively straight- 
forward functions. 


When an application requires the creation of new files, the 
new files must be filled with data. This process is called 
populating the file. A series of successive STORE state- 
ments is used for this purpose. With the STORE statement, 
VAX-11 DATATRIEVE prompts the user for each field 
value and, before accepting input, performs any validation 
checks specified by the record format description. 


Data Retrieval 
VAX-11 DATATRIEVE allows stored data to be retrieved in 


an easily understood form, regardless of underlying data 
structure (RMS or DBMS) or location (local or remote us- 
ing DECnet-VAX software). 


The data retrieval statements of VAX-11 DATATRIEVE are 
simple and particularly powerful statements with English- 
like syntax. They consist of verbs modified by a Record 
Selection Expression (RSE). The RSE defines a subset of 
the records in the domain. These records are then se- 
lected by VAX-11 DATATRIEVE for retrieval. One state- 
ment can get the answer to a casual query or produce a 
long, detailed report. 


Ad hoc information retrieval with VAX-11 DATATRIEVE 
can be performed as an iterative process, using a series of 
statements to progressively narrow down the group of re- 
cords to be retrieved. This is accomplished by using a 
FIND request with a specified domain as its object to esta- 
blish what is called the current collection. Subsequent 
FIND requests progressively narrow down the current col- 
lection until the user is satisfied with the results. RSEs can 
be as simple or as complex as a user wants. 


Report Writer Facility 
In addition to query commands, VAX-11 DATATRIEVE 


provides a facility to generate reports. The VAX-11 DATA- 
TRIEVE REPORT statement produces formatted reports 
without formatting statements, but allows the user to over- 
ride its default formats when necessary. A title, column 
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header, and page numbers are produced automatically. 
Simple (AT TOP OF.....AT BOTTOM OF...) statements cre- 
ate page headers, page trailers, headers and trailers for 
control breaks, and a report summary. The language con- 
structs used within the REPORT statement are a subset of 
the VAX-11 DATATRIEVE; they include all the statistical 
functions. Reports can be generated from data stored in 
VAX-11 RMS files, VAX-11 DBMS databases, or DATA- 
TRIEVE VIEWS that combine several domains, without any 
change in the syntax of the REPORT statement. 


Commands to the report facility are simply an extension of 
query facility commands. Although the report facility pro- 
vides extensive formatting capabilities, its default settings 
are suitable for many applications, further simplifying its 
use. Furthermore, errors in commands are discovered im- 
mediately (as in the query facility), so the user can correct 
the commands before printing erroneous or incomplete 
reports. 


Graphics 

The VAX-11 DATATRIEVE graphics capability includes 
histograms, bar charts, pie charts, xy scatter diagrams, 
and time-series graphs. Using the PLOT verb, plots can be 
displayed on a VT125 terminal and printed via an attached 
printer. This does not require a different syntax. It uses the 
results of a FIND and provides another way for users to 
view information. The data is presented in a manner that is 
meaningful to the user. 


Forms 

VAX-11 DATATRIEVE can be used with VAX-11 FMS to 
provide forms input and output. The application designer 
defines the form and names it as part of a VAX-11 DATA- 
TRIEVE data definition. VAX-11 DATATRIEVE automati- 
cally generates the proper FMS calls when data associated 
with a form definition is input or retrieved. 


Ease-of-Use Features 
VAX-11 DATATRIEVE supports several features that make 


the system attractive to use for all levels of computer user. 


The Application Design Tool (ADT) is a VAX-11 DATA- 
TRIEVE utility that simplifies the process of defining 
domains and record formats, and the creating of VAX-11 
RMS files. Operating in interactive mode, ADT presents 
the user with a series of simple questions. The user’s re- 
sponses provide ADT with information to generate the 
proper definitions. For RMS files, ADT will prompt the user 
to get a full set of parameters pertaining to organization, 
index keys, etc. ADT will then create an indirect command 
file that the user can execute immediately or at some later 
time to create the desired RMS file. 


VAX-11 DATATRIEVE provides a self-teaching facility 
called ‘Guide Mode’. In this mode of operation, users are 
guided through their VAX-11 DATATRIEVE sessions with a 
series of prompts that show at each step options are avail- 
able. 


VAX-11 DATATRIEVE provides its own editor that closely 
resembles the standard VAX editor, EDT. It can be used in 
either line or character mode, with or without keypad com- 
mands. The editor lets the user correct typing or syntax er- 
rors in VAX-11 DATATRIEVE statements without having to 
completely retype the statements. 


Advanced Features 
VAX-11 DATATRIEVE supports advanced features to give 
experienced users a full range of capabilities. 


VAX-11 DATATRIEVE has an important relational facility 
for linking multiple record types dynamically. Using the 
CROSS operator, records from separate domains can be 
joined dynamically in a single retrieval statement. These 
domains can contain data from RMS files or DBMS data- 
bases. This is an especially powerful facility that enables 
users to join records from any files related to one another 
by acommon field. 


Procedures can contain references to other procedures 
(nested procedures), provided that no procedure invokes 
itself either directly or indirectly. 


The use of hierarchies allows for the manipulation of com- 
plex data that contains lists and sublists. A hierarchy can 
be defined as a single file with a repeating group or multi- 
ple domains that are automatically cross-linked. Exten- 
sions related to hierarchies include the inner print list (to 
override default formatting of a sublist) and the ANY 
Boolean expression that allows VAX-11 DATATRIEVE to 
search a sublist for the existence of a particular record. 


Calling VAX-11 DATATRIEVE 

All the functions of VAX-11 DATATRIEVE — with the ex- 
ception of the editor, Guide Mode, and ADT — can be 
called from all application languages via the standard 
VAX/VMS call interface. This provides the appropriate tool 
to solve a programming problem (i.e.,FORTRAN number- 
crunching, or DATATRIEVE access). 


VAX-11 COMMON DATA DICTIONARY 

The VAX-11 Common Data Dictionary is a central reposi- 
tory for data about data. It integrates the VAX information 
management products — including VAX-11 DATATRIEVE 
and VAX-11 DBMS — by making it possible for them to 
use a single set of data descriptions as a common re- 
source. 


VAX-11 DATATRIEVE uses the VAX-11 Common Data Dic- 
tionary to store logical record (domain) definitions and, 
when DECnet software is used, to store forwarding ad- 
dresses of data stored in remote nodes. 


VAX-11 DBMS uses the VAX-11 Common Data Dictionary 
to store the database data definitions it shares with the 
VAX languages and VAX-11 DATATRIEVE. 


The VAX-11 Common Data Dictionary is built from one or 
more physical dictionary files; these make up the one logi- 
cal dictionary. It has one integrated directory that is an in- 
dex to both the VAX-11 DATATRIEVE and VAX-11 DBMS 
data definitions it contains. The directory is organized asa 
hierarchy that has a structure closely resembling that of 
the VAX/VMS file system directory. 


A security model based on the hierarchical directory is 
maintained by the VAX-11 Common Data Dictionary. Each 
directory and data description can have its own access 
control list. The access control list specifies a class of user 
as well as the type of access to the directory or data de- 
scription. User classes can be selected by combining UIC 
(User Identification Code), user name, password, and ter- 
minal-class parameters as well as local and remote 
terminal ID. 


For VAX-11 DATATRIEVE, the VAX-11 Common Data 
Dictionary stores record format descriptions and domain 
definitions for VAX-11 RMS files and VAX-11 DBMS data- 
base structures. The VAX-11 Common Data Dictionary 
also contains VAX-11 DATATRIEVE procedures, tables, 
and plot definitions. 


For VAX-11 DBMS, the VAX-11 Common Data Dictionary 
stores database data descriptions of three types — 
schema, subschema, and storage schema. These defi- 
nitions are used by VAX-11 DBMS to build — later refer- 
ence — database structures. 


The schema is the master data definition for a logical data- 
base. It contains all record, data item, and set relationship 
definitions. There is one schema per database. The 
subschema definitions are application-program views of 
the data, of which there may be many for one database. 
They are also used by the language compilers during the 
compilation process. The storage schema is the master 
data definition for the physical structure of a database. 
There is one storage schema per database. 


The Dictionary Management Utility is a utility for managing 
the VAX-11 Common Data Dictionary. The DMU can be 
used to backup and restore the VAX-11 Common Data 
Dictionary, to create and delete the VAX-11 Common Data 
Dictionary objects, to create and delete dictionary directo- 
ries on any level, and to create and delete access control 
lists. 


The DMU can be used to display all or part of the directory 
structure and to display selected information about a par- 
ticular object. It also has a ‘HELP’ facility. 


The VAX-11 Common Data Dictionary can maintain a his- 
tory of dictionary activity. It will display on command the 
access history of specified objects and directories. 


The CDDL (Common Data Definition Language) utility 
provides a generic facility to enter, modify, and display re- 
cord definitions for the VAX languages. Once a record def- 
inition has been entered in the CDD, it can be used by the 
language compilers or VAX-11 DATATRIEVE. This means 
that only one definition per record needs to be stored in 
the CDD. 


VAX-11 DBMS 

A database management system (DBMS) enables or- 
ganizations to centralize all their valuable data; by doing 
this, it can serve as one common pool for a variety of appli- 
cation programs. The database management system pro- 
vides an organization with the tools to manage and control 
access to this data by multiple users, to protect the 
integrity of the data, and to simplify access and reduce ap- 
plication maintenance costs. 


Because DBMS provides data independence capabilities, 
many different users of information within the corporation 
can access this common pool of information; thus simpli- 
fying and speeding access time. And because many users 
are accessing this data, it is important to ensure the in- 
tegrity of the data; to be certain that users have the proper 
data definitions and that an incremental backup has 
occurred when new information has been added. 


9-16 


The same principle applies to the storage of data. When all 
data are stored in acommon place, data redundancy is re- 
duced. 


Once a common database design is put into operation, eli- 
gible users can access complete and timely information 
automatically and easily. Application programs become 
shorter because common functions are performed by the 
DBMS. Installation growth is simplified because alteration 
of the database is done only once, rather than once for 
each form in which the data are stored. 


Creating a database is a centralizing act. The database 
can increase the efficiency of distributed processing by 
making information developed at one node available at all 
nodes to users who have legitimate need for it. 


With a database management system, data protection and 
data integrity are ensured. The use of subschemas creates 
levels of security under which users can access only the 
information they need to have. The liklihood of important 
files being deleted or erroneously updated is reduced be- 
cause there are fewer complex accesses to the informa- 
tion. 


VAX-11 DBMS is a full-scale CODASYL-compliant general 
purpose database management system. It is based on the 
March 1981 Working Document of the ANSI Data Defi- 
nition Language Committee. 


Because it uses powerful network-type data structures, 
VAX-11 DBMS can accommodate complex data relation- 
ships. Data can be accessed directly from application pro- 
grams or it can be accessed through VAX-11 DATA- 
TRIEVE. 


Included with the VAX-11 DBMS facility is an important 
productivity tool, DBQ — an interactive program-callable 
database query language that makes it easy to write and 
check VAX-11 DBMS DML statements. It provides a pic- 
ture display of a portion of a database. 


VAX-11 DBMS uses the VAX-11 Common Data Dictionary 
to store database data descriptions of three types — 
schema, subschema, and storage schema. These defi- 
nitions are used by VAX-11 DBMS to build and later refer- 
ence database structures. 


Data Definitions 

A program is commonly defined as the sequence of in- 
structions, data, and routines necessary for the solution of 
a problem. Yet, the logic of problem solving does not 
require that data definitions be an integral part of the pro- 
gram. 


When data definitions are included in programs, if differ- 
ent definitions are created for the same data it can lead to 
data redundancy and inconsistency. Separating the defi- 
nition of the data from the program avoids multiple 
definitions. 


VAX-11 DBMS separates data definitions from data pro- 
gramming by using Data Definition Languages (DDLs) to 
define data. VAX-11 DBMS has three DDLs: the schema 
DDL, the subschema DDL, and the storage schema DDL. 


Schema 
A schema is a logical description of the data characteris- 
tics and relationships in a database. A schema DDL is 


used to define a schema. The schema DDL defines all data 
items and records in the database and describes all logical 
relationships, called sets, that are to exist between re- 
cords. 


Centralizing data definitions in the schema avoids multiple 
definitions and makes it easier for users to share the same 
data. 


Within a VAX-11 DBMS database, the basic accessible 
unit is called an item. Items can be simple fields or they 
can be vectors. Records are composed of items. The 
Schema defines the format of individual records, differen- 
tiating them from one another. For instance, one record 
type can include record occurrences that have the follow- 
ing data items: 


e eight characters for employee badge number 
e 32 characters for employee name 
e 32 characters for employee address 


Any number of record types can be defined, depending on 
the need of the user. 


A major feature of database programming is that records 
can be directly linked in relationships called sets. With 
VAX-11 DBMS, users can define relationships between re- 
cords in a schema. 


Set construction is based on an owner-member concept. 
One record “owns” a collection of other records in a one- 
to-many relationship(s); the relationship is called a set oc- 
currence. A set type defines the type of sets that can exist 
in the database; it names the relationship and defines the 
record type that is valid for the “owner”, and the record 
type that is valid for the “members”. 


An area is a specific logical subdivision of storage space in 
the database that can contain occurrences of records of 
various types. 


This completes the logical definition of the database. The 
schema now contains the definitions of the contents and 
the structure of the database. Using the schema, a pro- 
grammer can determine what data is available in the data- 
base before designing applications. 


The record order for each set is defined in the schema by 
independently describing each set. Record order within a 
set can be defined to be: 


e FIRST — new records are inserted first in a series of re- 
cords. 

e LAST — new records are inserted last in a series of 
records. 

e PRIOR — new records are placed immediately before a 
record occurrence established by a user program. 


e NEXT — new records are placed immediately after a re- 
cord occurrence established by a user program. 


e SORTED — records are logically placed in ascending or 
descending order. Placement order is determined by 
the value of one or more data items within the record. 


The logical ordering of record occurrences in a set is inde- 
pendent of the physical placement of records. A record 
can also be a member of many different sets and can have 
a different relationship in each set. Also, the type of mem- 
bership can be different in each set. Participation in a set 
can be optional, mandatory, or fixed; manual or automatic. 


These options affect the use of statements to CONNECT, 
RECONNECT, and DISCONNECT records from the set. 
CONNECT, RECONNECT, and DISCONNECT are DML 
modification statements that cause a change in the set re- 
lationship of an existing record occurrence in the data- 
base. 


OPTIONAL set membership permits removal of a record 
from a set (DISCONNECT) without causing it to be deleted. 


FIXED set membership defines a record as a permanent 
member of the set as long as the record exists in the data- 
base. 


MANDATORY set membership means that a record can 
not be DISCONNECTed from a set, but it may be RECON- 
NECTED to a different set occurrence. 


AUTOMATIC set membership means that DBMS will auto- 
matically connect the record to the set then the record is 
first stored in the database. 


MANUAL set membership means that no automatic CON- 
NECT is performed. 


Subschema 

After the schema is defined, a logical subdivision can then 
be defined using subschema DDL. The subschema is a 
subset of the schema; it is the logical interface between the 
application and the database. And, while defining how the 
data can be accessed, the subschema describes those 
data items, records, and sets that are available to a partic- 
ular application program. 


A subschema can also be viewed as a security window that 
ensures the privacy and integrity of the database. 


Data security is also provided by protecting data defi- 
nitions in the VAX-11 Common Data Dictionary with ac- 
cess-control lists at each node of the hierarchical 
directory. 


Storage Schema 

The storage schema effects the separation of the physical 
characteristics of the data from the logical definition of the 
data. It tells VAX-11 DBMS how records and sets are to be 
stored. By separating logical data definitions from physical 
data definitions,the programmer need not be concerned 
how the data is actually stored. 


Because of the data independence, the storage schema 
can be changed without affecting any application pro- 
grams and can be “tuned” for performance and storage 
efficiency. 


VAX-11 Common Data Dictionary (CDD) 

The Common Data Dictionary (CDD) is the central 
VAX/VMS storage facility for information about data ele- 
ments, data structures, and relationships between data 
structures for VAX-11 DBMS and VAX-11 DATATRIEVE. 
The CDD does not contain actual data files; rather, it con- 
tains definitions. Storing data definitions in this central sto- 
rage facility allows them to be independent of their physi- 
cal implementation. Programs compiled against a data 
description in the CDD can be run with any file or database 
that is created using that data description. 


9-18 


Database Access 

Each application program accesses a subdivision of the 
database through a simple set of commands that acts both 
as an extension to COBOL and FORTRAN programs and 
as a call from BASIC and MACRO programs. The data- 
base can be accessed by application programs directed 
by the subschema (that has been predefined by the data- 
base administrator). The subschema, which is first 
NAMED in the program, includes record descriptions. The 
programmer can, therefore, logically manipulate the infor- 
mation in the database using one of two methods provided 
by VAX-11 DBMS: 

® Data Manipulation Language — a set of high-level state- 
ments that create syntactical and logical extensions to 
FORTRAN and COBOL. General types of DML state- 
ments are Control Statements (READY,COMMIT, ROLL- 
BACK); Retrieval Statements (GET, FETCH, FIND); and 
Modification Statements (CONNECT, DISCONNECT, 
MODIFY, RECONNECT,STORE). 

Call Statement Interface — used for any VAX-11 lan- 
guage that supports the VAX/VMS calling standard. 
Programs written in these languages call DBQ to access 
a database. The same set of statements are available as 
in the host language DMLs. VAX-11 DBMS provides a 
User Work Area (UWA) generator to facilitate program 
development. 


FORTRAN DML 

FORTRAN applications allow for DML statements to be 
embedded directly into a FORTRAN program. The FOR- 
TRAN DML preprocessor extracts the required sub- 
schema information from the VAX-11 Common Data Dic- 
tionary and interprets the DML for input to the VAX-11 
FORTRAN compiler. The output is fed into the FORTRAN 
compiler, producing an object file. 


COBOL DML 

COBOL applications allow for DML statements to be 
embedded directly into a COBOL program in addition to 
using the call interface. The COBOL compiler extracts the 
required subschema information from the VAX-11 Com- 
mon Data Dictionary and produces an object file. 


DBQ 

DBQ is a callable database query interface; it is used by 
other VAX languages to access VAX-11 DBMS. 
Interactively, it executes COBOL-like data manipulation 
commands and automatically generates VT 100 displays of 
easy-to-follow schematic diagrams that illustrate access 
paths. On the VT100 terminal, DBQ uses a split screen to 
show the results of each statement. Interactive DBQ can 
be used in several ways: 

® to retrieve data 

® to test and debug DML program logic 

® to carry out low-volume updating and reporting 

® to learn how to use a database 

® to update a database by storing records 

Using DBQ, data manipulation operations can be tested 


against actual data structures. This is particularly useful 
when checking application program designs. 


CREATING A DATABASE 

The Database Operator (DBO) utility is a central point of 
control for the day-to-day operation and management of a 
database. It converts coded schema, subschema, and sto- 
rage schema information from the VAX-11 Common Data 
Dictionary into data files and control information that the 
DBCS can use at runtime. The result of the database crea- 
tion stage is referred to as an empty database. The proc- 
ess of filling a database with data is called database 
population. Database population is done with user-written 
programs that are usually regular application programs 
for adding records in an operational context. 


Integrated Database Administration with DBO 

The Database Operator utility provides the Database Ad- 

ministrator with all of the functions required to create, 

maintain, delete, and control VAX-11 DBMS databases. It 

provides the following: 

e Reports on VAX-11 DBMS information in the VAX-11 
Common Data Dictionary. 


e Extraction of DDL source from the VAX-11 Common 
Data Dictionary. 


® Deletion of DDL information in the VAX-11 Common 
Data Dictionary. 

® Verification of the integrity of internal database struc- 
tures. 

® Modification of the contents of corrupted database sto- 
rage areas (this function is not recommended nor re- 
quired for normal usage). 


© Formatted database dumps. 

® Full and incremental database backup. 

e Database restoration from backup and after-image 
journals. 

e Control and display of the status of the DBCS monitor 
process. 


e Database access statistics. 
@ Analysis of database structures. 


® Generation of a User Work Area (UWA) for application 
programs using the callable DBQ interface. 


Simple Restructuring Without Reload 

Fields, record types, and most new set relationships can 
be added without having to unload and reload the data- 
base. This feature is especially useful for applications that 
grow over time. 


Database Verification with DBO/VERIFY 

VAX-11 DBMS has a database verification utility called 
DBO/VERIFY. This utility can be used to check the in- 
tegrity of any database a user suspects might be cor- 
rupted. It checks for valid set linkages and database page 
formats. 


Multiuser Support with Concurrency Control 

VAX-11 DBMS provides full concurrent access and update 
capabilities with automatic record-level locking. The appli- 
cation developer does not have to be concerned with 
multiuser contention for data records (by declaring and re- 
leasing data locks) because this is performed automati- 
cally. In addition, users will always see a consistent view of 
the database. 
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Transaction Rollback 

VAX-11 DBMS performs automatic transaction rollback. A 
transaction is a logical unit of work in an application pro- 
gram bounded by program quiet points. A program quiet 
point occurs when a program is first activated or when a 
COMMIT or ROLLBACK command is executed. If a 
process aborts or issues a ROLLBACK command, all up- 
dates not yet committed will be automatically backed out. 


Journal Recovery 

VAX-11 DBMS always stores before-images of uncommit- 
ted updates and, optionally, keeps long-term after-image 
journals of all database updates. These journal records 
are used to recover from program, system, or hardware 
failure. 


After a program or system malfunction, VAX-11 DBMS will 
roll back all uncommitted transactions using the before- 
image journal. If data has been destroyed, VAX-11 DBMS 
can roll forward from a backup copy of the database, using 
the after-image journal to reapply all committed transac- 
tions. 


Multiple Databases 

VAX-11 DBMS allows multiple databases to be online at 
the same time. This is useful when totally independent 
data must be maintained in separate databases that have 
different schemas. It is also useful in the more commonly 
encountered situation of the single schema that applies to 
both a test and production database. However, a single 
VMS process can only access one database at a time. 


VAX-11 FORMS MANAGEMENT SYSTEM (FMS) 

VAX-11 Forms Management System (FMS) is a utility 
package used to provide video-form support for applica- 
tions on the VT100 video terminal. VAX-11 FMS provides a 
flexible, easy-to-use interface between the form applica- 
tion program and the terminal user. FMS allows a terminal 
user to develop form applications using native-mode lan- 
guage processors for VAX-11 COBOL-74, VAX-11 
COBOL, and VAX-11 PL/I. Documentation is provided to 
enable programmers to call FMS from other languages. 


Using Forms in an Application 

VAX-11 FMS forms include a video-screen image 
comprising data fields and constant background text, 
along with protection and validation attributes for individ- 
ual data fields. The data fields and background text can be 
highlighted using any combination of the VT100 video at- 
tributes: reverse video, underline, blink, and bold charac- 
ters. Split-screen and scrolling capabilities allow the user 
to view more data than can be displayed on the screen at 
one time. 


Individual data fields can be display-only, enter-only (no 
echo), or can be restricted to modification by privileged 
users. Data fields can be formatted with fill characters, de- 
fault values, and other formatting characters — such as 
the dash in a phone number — all of which assist the ter- 
minal operator, but are not visible to the application pro- 
gram. Fields can be right- or left-justified or can use a spe- 
cial fixed-decimal data field type to normalize floating- 
point decimal numbers into fixed point for easier use in 
computation. 


Field validation includes checking each keystroke in a field 
for the proper data type (e.g., alphabetic, numeric, etc.). 
Fields can also be defined as ‘must enter” or “must com- 
plete.” 


A line of HELP information can be associated with each 
field, and a chain of one or more HELP forms can be asso- 
ciated with each form. If people need additional instruc- 
tions while using a form, they can press the HELP key to 
display the HELP line for the current field. A second HELP 
keystroke displays the first HELP screen for the current 
form so that, from any point in the application form, the 
user can get to an entire series of HELP forms. In this way 
the entire user manual for an application can be put online 
and automatically keyed to the appropriate user form. 


Almost any class of application can benefit from using 
VAX-11 FMS. Source data entry and _ inquiry/ 
response/update are the most obvious types of forms-or- 
iented uses, but other types of programs can benefit 
equally well. For example, a simulation or numerical ana- 
lysis program could use FMS forms to explain and accept 
input parameters, and then to format and scroll through 
the output of the run. Forms might constitute the front end 
of a student registration or a computer-aided instruction 
system. Alternatively, they could be used to review data 
acquired from laboratory or factory instrumentation or to 
format the operator input of control parameters to such 
processes. Almost any application that uses alphanumeric 
video terminals can be enhanced by using FMS forms to 
talk to the terminal user. 


Developing Applications with VAX-11 FMS 

VAX-11 FMS forms are created and modified interactively 
on the screen via a special FMS utility called the Form Edi- 
tor (FED). Because the video image is typed and manipu- 
lated directly on the screen, there is no need to lay out a 
form on a paper chart or to code complex specifications 
into a form definition program written in a difficult lan- 
guage. Rather, the form creator always sees the form on 
the screen exactly as it would appear to the application 
user. A set of 24 editing and data manipulation functions 
that are invoked through the function keypad of the VT 100 
terminal allow for easy alteration of the form description. 


Fields are defined interactively via the function keypad and 
by typing the COBOL-like picture character for each posi- 
tion of the field directly on the screen. The remaining field 
attributes, such as field name, default value, and the con- 
tents of the HELP line, are described by interactively filling 
in a questionnaire form on the screen. Another form is 
used to define certain characteristics that apply to the form 
as a whole — such as the name of the form and of the first 
HELP form associated with it — and whether the screen is 
to be placed into reverse-video or 132-column mode. A 
third form is used to specify application constants, called 
“named data,” which can be stored with the form instead 
of hard-coded into the application program. This last fea- 
ture allows such application parameters as small data ta- 
bles, filenames, names of subsequent forms, etc., to be 
stored with the form and edited almost interactively. 


When the application developer is satisfied with the 
appearance and content of the form, the Form Editor 
writes the form out into a workfile. The Form Utility (FUT) is 
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then used to insert the form into a new or existing form li- 
brary, from which it will be retrieved when the application 
program is executed. The Form Utility may be used to per- 
form other maintenance functions on form libraries, as 
well as to generate hardcopy descriptions of forms suit- 
able for inclusion in application documentation. FUT can 
also generate COBOL Data Division code to correspond to 
the form description. 


Once the form has been stored in a form library, one or 
more application programs must be coded in order to use 
it. These application programs control the interaction 
between themselves, the form, and the operator, by mak- 
ing calls to a library of VAX-11 FMS subroutines called the 
Form Driver (FDV). Under the direction of the calling appli- 
cation program, the Form Driver displays forms, performs 
all the screen management an application requires, han- 
dles all terminal input and output, and validates each 
operator entry by checking it against the field description 
for the field. A broad selection of subroutine calls allows 
the program to communicate with the screen on either a 
full-screen or field-by-field basis. While the terminal oper- 
ator is typing data, all data validation and formatting, error 
messages, and HELP requests occur completely transpar- 
ent to the application program. 


Maintaining VAX-11 FMS Applications 

Several features of VAX-11 FMS make maintenance of ap- 
plications using forms both rapid and reliable. The most 
obvious such feature is the interactive editing capability of 
the Form Editor. Capabilities such as Open Line for insert, 
Cut and Paste, etc., make modifications to existing forms 
quick and easy. Furthermore, when fields are moved 
around on the screen, their attributes are preserved, so 
that reentry of the form is not required. 


Perhaps the most important contribution to application 
maintainability comes from the fact that the application 
makes all references to screen data by field name. These 
field name references are not resolved until the program 
executes, so the form description is actually independent 
of the application program. This means that it is easy to 
write programs that do not know or depend upon the spe- 
cific order of the fields or even know the names or each 
field. This capability, combined with the storage of forms in 
libraries, means that, in many cases, the form can be rear- 
ranged or new fields added, without requiring that the ap- 
plication program be recompiled or relinked. 


The last feature of VAX-11 FMS that promotes application 
maintainability is the ability to store application 
parameters with forms as named data. Parameters such 
as the names of related forms or programs, file specifica- 
tions, small look-up tables, range check boundaries, and 
error messages specific to the particular form can be 
stored with the form and edited with the same rapidity and 
ease. For example, imagine an application that will be 
used by operators who speak a variety of different lan- 
guages. The first thing the operator would do when logging 
into the application would be to select a language. The 
program would simply open the form library with all the 
forms translated into that language. Named data would be 
used to store all other language-dependent application 
parameters, such as program-generated error messages, 
abbreviations (Y=YES or O=OUI or S=SIl), etc. The same 


program code would then be executed regardless of the 
language the application would “speak.” A new language 
could be added simply by modifying the initial language 
selection form and creating a form library with the forms 
and named data translated into the new language. 


VAX-11 SORT/MERGE 

VAX-11 SORT/MERGE is a native mode utility that can be 
run interactively, as a batch job, or called from a user-writ- 
ten VAX-11 native-mode program. 


The SORT utility allows the user to reorder data from one 
to ten input files into a single output file in a sequence 
based upon user-specified key fields within the input data 
records. If the user does not wish to physically reorder the 
input, SORT can be used to extract key information as a 
permanent file. That file can then be used to access the or- 
iginal input file in the order of the key information in the 
sorted file. 


SORT provides four sorting techniques: 

e Record Sort produces a reordered data file by moving 
the entire contents of each record during the sort. A re- 
cord sort can be used with any acceptable VMS input 
device and can process any valid VAX-11 RMS format. 


Tag Sort produces a reordered data file by moving only 
the record keys and pointers to the records’ addresses 
within the file during the sort. SORT then randomly 
reaccesses the input file to create a resequenced output 
file according to those record keys. The tag sort method 
conserves temporary storage, but can accept only input 
files residing on disk. 


Address Sort produces an address file without reorder- 
ing the input file. The address file contains RFAs, a 
pointer to each record's location in the file that can later 
be used as an index to read the database in the desired 
sequence. Any number of address files can be created 
the same database. A customer master file, for instance, 
can be referenced by customer-number index or sales 
territory index for different reports. Address sort is the 
fastest of the four sorting methods. 


e Index Sort produces an address file containing the key 
field of each data record and a pointer to its location in 
the input file. The index file can be used to randomly ac- 
cess data from the original file in the desired sequence. 


The MERGE utility permits the user to merge data from 
two to ten similarly sorted input files. The MERGE utility 
merges the data according to key field(s) defined by the 
user and generates a single output file. The input files to 
be merged must all be in the same sequence i.e., the 
MERGE key fields must be the same as those used to sort 
the files. 


The following example illustrates the sorting of a sales re- 
cord file by customer last name. The name of the initial file 
is SALES.DAT. Each record contains six fields: date of 
sale, department code, salesperson, account number, 
customer name, and amount of sale. The numerical 
ranges listed below the set of records indicate the position 
and size of each information field within the record. 
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DATE DPT SALESP ACCT CUST-NAME AMT 
091580 25 Fielding 980342 CoolidgeCarol 24999 
091580 25 Sanchez 643881 McKeeMichael 2499 
091580 25 #£=Bradley 753735 RiceAnne 10875 
091580 19 Arndt 166392 Wilson Brent 1298 
091580 28 Meredith 272731 Karsten Jane 4000 
091580 25 Bradley 829582 OlsenAllen 3350 
091580 19 Erkkila 980342 CoolidgeCarol 7200 


RIN a I Ne ee) 
1-7 8-10 11-21 22-28 29-58 59-65 


The user may now rearrange the sales records in file 
SALES.DAT according to any of the file’s information 
fields. For instance, to sort the file in alphabetical order of 
customer’s last name, the user would type the following 
command sequence: 


$ SORT/KEY =(POSITION=29,SIZE=30) SALES.DAT 
BILLING.LIS <cr> 


In this command sequence, the user is defining the SORT 
key to be the customer’s last name and the output file to be 
BILLING.LIS 


The user may now obtain a listing of the sorted data file by 
using either the TYPE or PRINT commands. 


$ TYPE BILLING.LIS 


DATE DPT SALESP ACCT CUST-NAME AMT 
091580 19 ~~ Erkkila 980342 CoolidgeCarol 7200 
091580 25 _ Fielding 980342 CoolidgeCarol 24999 
091580 28 +Meredith 272731 Karsten Jane 4000 
091580 25 Sanchez 643881 McKeeMichael 2499 
091580 25 #£=Bradley 829582 Olsen Allen 3350 
091580 25 #£=Bradley 753735 RiceAnne 10875 
091580 19 #£Arndt 166392 Wilson Brent 1298 


To perform the MERGE function, the MERGE utility ex- 
pects presorted data files upon which to operate. In the 
following example, MERGE is operating upon two presort- 
ed (by alphabetical order) sales data files, STORE1.FIL 
and STORE2.FIL. 


STORE1.FIL 
DATE DPT SALESP ACCT CUST-NAME AMT 
091580 19 Erkkila 980342 CoolidgeCarol 7200 
091580 25 Fielding 980342 Coolidge Carol 24999 
091580 28 Meredith 272731 Karsten Jane 4000 
091580 25 Sanchez 643881 McKeeMichael 2499 
091580 25 Bradley 829582 Olsen Allen 3350 
091580 25 Bradley 753735 RiceAnne 10875 
091580 19 #£4Arndt 166392 Wilson Brent 1298 
STORE2.FIL 
DATE DPT SALESP ACCT CUST-NAME AMT 
091580 20 OConnor 358419 Beaulieu Ronald 1598 
091580 04 #+7Docus 980342 Coolidge Carol 575500 
091580 25 _ Fielding 669011 Fernandez Felicia 12000 
091580 35 Leith 848105 Kingsfield Stanley 5550 
091580 04 Kramer 561903 Landsman Melissa 230000 
091580 20 OConnor 643881 McKee Michael 995 
091580 19 Erkkila 454389 VanDerling Julie 5480 


To merge the two data files, the user must type the follow- 
ing command sequence: 

$ MERGE/KEY =(POSITION=29,SIZE=30) 
STORE1.FIL,STORE2.FIL CENTR.FIL <cr> 

The user has indicated in the above command sequence 
that the files are to merged via the alphabetical order of 
the customer’s last name. The user can examine the out- 
put file via the PRINT or TYPE commands. 


$ TYPE CENTR.FIL <cr> 


DATE DPT SALESP ACCT CUST-NAME AMT 
091580 20 OConnor 358419 Beaulieu Ronald 1598 
091580 19 Erkkila 980342 Coolidge Carol 7200 
091580 25 Fielding 980342 Coolidge Carol 24999 
091580 04 +7Docus 980342 Coolidge Carol 575500 
091580 25 Fielding 669011 Fernandez Felicia 12000 
091580 28 Meredith 272731 Karsten Jane 4000 
091580 35 Leith 848105 Kingsfield Stanley 5550 
091580 04 Kramer 561903 Landsman Melissa 230000 
091580 25 Sanchez 643881 McKee Michael 2499 
091580 20 OConnor 643881 McKee Michael 995 
091580 25 Bradley 829582 Olsen Allen 3350 
091580 25 Bradley 753735 RiceAnne 10875 
091580 19 Erkkila 454389 VanDerling Julie 5480 
091580 19 £4Arndt 166392 Wilson Brent 1298 


VAX-11 SORT/MERGE FEATURES 

VAX-11 SORT/MERGE can perform the following func- 

tions: 

e Reorder data files to ascending or descending sequence 
on up to ten keys user specified. 

e Merge up to ten sorted input files into one sorted output 
file. 

e Create reordered address files of RFAs and keys for 
software used. 

e Sort or merge fixed, variable, and VFC records. 

e Sort or merge ASCII character keys in ASCII or EBCDIC 
sequence. 

e Sort or merge sequential, relative, indexed-sequential 
files. 

e Sort or merge keys can be character, decimal, binary, 
unsigned binary, F_,D_,G_, and H floating data types. 

e SORT can determine its own work file requirements 
based on input file RMS information received. 

e SORT can be controlled by a command string or specifi- 

cation file. 

SORT can be tuned for maximum efficiency. 

e SORT provides four processing techinques: record, tag, 
address, index. 

e Sort or merge input files from any VAX/VMS input de- 

vice. 

Output sorted data files to any VAX/VMS output device. 

SORT prints out statistics upon completion when 

requested 

e Be invoked by a single command string, or can prompt 
the operator for input and then output file specification. 


e Respond with unique SORT/MERGE error messages in 
VAX/VMS format. 
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e Optional sequence checking of input files on merge. 
VAX-11 SORT/MERGE supports the following key for- 
mats: 
e Character data are ASCIl. 
e ASCII and EBCDIC collating sequence. 
e Binary data are VAX representation. 
e Packed-decimal data are VAX representation. 
e Zoned-decimal data are VAX representation. 
e Unsigned binary and F_,D_,G_, and H floating. 
e String-decimal data format can be: 
- leading separate sign 
- leading overpunched sign 
- trailing separate sign 
- trailing overpunched sign 


SORT/MERGE as a Set of Callable Subroutines 


SORT/MERGE can be used as a set of callable subrou- 
tines from any native VAX language. This subroutine pack- 
age provides two functional interfaces to choose from: a 
file I/O interface and a record I/O interface. Both 
interfaces share the same set of routines, and the same 
calls are used for all languages. 


SORT and MERGE subroutines are callable from VAX-11 
COBOL using the standard COBOL SORT and MERGE 
verbs. 


For either interface, the user can supply a key comparison 
routine. This feature allows the user the flexibility of de- 
parting from the key types supported by SORT/MERGE. 


File I/O Interface 

The file 1/O interface allows the user to specify the input 
files and an output file to SORT or MERGE. SORT then 
reads the data from the input file(s) and sorts the data into 
the output file. MERGE also reads the data form the input 
file(s) and merges it into one output file. 


Record I/O Interface 

The record I/O interface allows the user to pass each indi- 
vidual data record to SORT/MERGE, let SORT/MERGE 
order them and then receive each record back in the cor- 
rect order, individually, from SORT/MERGE. 


Programming Considerations 
Any program can use either SORT/MERGE subroutine in- 
terface with any of the VAX-11 native mode languages. 


SORT/MERGE PERFORMANCE FEATURES 
@e SORT/MERGE compiles a key comparison routine spe- 


cific to each sort or merge. This results in a substantial 
reduction of CPU usage. 

e Work files are not created until they are needed. This 
reduces overhead when sorting small files. 


e The numbers scratch files and their placement can be 
specified by the user at anytime. 
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DIGITAL offers a range of products to link tasks or processes together, whether 
they are running on the same or different systems. This capability allows com- 
puters to operate together in data communications networks for distributed 
processing. Specifically, DIGITAL offers three ways to interconnect computer 
systems, depending upon the systems involved: DIGITAL to DIGITAL, DIGITAL 
to other manufacturers, and DIGITAL to public packet switched networks. 


DIGITAL-to-DIGITAL computer networks are established through DECnet, a 
family of software products, protocols, interfaces, and support services de- 
signed specifically to link DIGITAL computer systems together. Such networks 
can contain computers that run the same or different operating systems. DEC- 
net networks expand the power of individual systems by integrating them with 
remote facilities to share data and peripherals and other data processing capa- 
bilities. At the same time, each DIGITAL computer and operating system in a 
DECnet network can be specialized for solving local problems. Using DECnet, 
various kinds of computer system networks can be constructed to facilitate 
remote communications, resource sharing, and distributed computation. DEC- 
net is highly modular and flexible. It is a set of services from which a user se- 
lects whatever is needed to build the network that will satisfy the requirements 
of a particular application. 


DECnet-VAX facilitates growth toward networking or distributed processing by 
providing the same interfaces in VAX/VMS itself as those used to communicate 
over a network. These interfaces can be utilized in programs and procedures 
used on a standalone VAX/VMS system even before purchasing DECnet-VAX. 
When requirements dictate the addition of more systems, DECnet-VAX pro- 
vides identical interfaces so that users need not reprogram even if 
communicating processes no longer run on the same system. 


Internet products comprise a software product family that enables DIGITAL 
systems to link with computers built by other vendors to form a network. The 
Internet products emulate communications protocols recognized and sup- 
ported by IBM, UNIVAC, CDC, and other systems. 


Packetnet products interconnect computer systems, networks, or terminals 
through public packet-switched networks. The common carrier provides the 
communications line and ensures system-to-system message delivery. The 
Packetnet products implement the X.25 recommendation for interfacing equip- 
ment to the packet-switched network. 


INTRODUCTION 

DIGITAL computers can communicate with other comput- 
ers either remotely or locally via a network. A network is a 
configuration of two or more independent computer sys- 
tems, called nodes, that are linked together to facilitate 
remote communication, share resources, and perform dis- 
tributed processing. Not all network nodes are required to 
run on the same type of operating system or even on 
equipment from the same manufacturer. Within the scope 
of a single network, several nodes with different operating 
systems and different features can interact to provide in- 
creased processing flexibility. 


Adjacent network nodes are linked together via carriers 
known as physical links. Physical links can be relatively 
permanent bonds, such as telephone lines or cable wires 
laid from one node to another, or they can be temporary 
connections that change with each use, such as dialup 
telephone links. 


In a network, several programs can use the same physical 
link to exchange data. This means more than one data 
path can be handled simultaneously by a physical link. The 
data path is known as a logical link. 


A variety of computer networks can be implemented using 
DECnet, Internet products, and Packetnet products. They 
typically fall into one of three classes: 

@¢ Communications Networks. These networks exist to 
move data from one, often distant, physical location to 
another. The data can be file-oriented (as is often the 
case for remote job entry systems) or record-oriented 
(as occurs with the concentration of interactive terminal 
data). Interfaces to common carriers, using both 
switched and leased-line facilities, are normally a part of 
such networks. Figure 10-1 illustrates a communications 
network. 
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Communications Network 


@ Resource-Sharing Networks. These networks exist to 
enable sharing expensive computer resources among 
several computer systems. Shared resources not only 
include peripherals like as mass storage devices, but 
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they can also include logical entities, such as a central- 
ized database that is made available to other systems in 
the network. These networks are often characterized by 
the concentration of high-performance peripherals, ex- 
tensive databases, and large programs on one or two 
host systems in the network. Typically, the satellite sys- 
tems have less expensive peripherals and smaller pro- 
grams. Figure 10-2 illustrates a resource-sharing net- 
work. 


VAX-11/750 


LARGE 


PRINTER DISK 


VAX-11/780 


VAX-11/730 


Resource-Sharing Network 


Figure 10-2 


Distributed Computing Networks. These networks 
coordinate the activities of several independent comput- 
ing systems and the exchange of data among them. Net- 
works of this nature can have specific geometries (star, 
ring, hierarchy), but often have no regular arrangement 
of links and nodes. These networks are usually config- 
ured so that the resources of a system are close to the 
users of those resources. Distributed computing 
networks are usually characterized by multiple comput- 
ers with applications programs and databases distrib- 
uted throughout the network. Figures 10-3 and 10-4 illu- 
strate two such networks. 
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Figure 10-3 
Typical Manufacturing Network 
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Computational Network 


DIGITAL NETWORK ARCHITECTURE 

The DIGITAL Network Architecture (DNA) is a set of 
protocols governing the format, control, and sequencing 
of message exchange for all DECnet implementations. 
DNA controls all data that travel throughout a DECnet net- 
work and provides a modular design for DECnet. 


The functional components of DNA are defined in layers 
wherein each DNA layer is designed to fulfill specific func- 
tions within the network. 


DNA consists of the following layers: 

e The User Layer, which encompasses user-written pro- 
grams and services that access the network. It is the 
highest layer in the architecture. 


® The Network Management Layer, which defines the 
functions that allow the system manager to oversee, 
control, maintain, and test all major facets of a network 
node. Unlike most other layers, it has interfaces defined 
not only for adjacent layers but also for every other layer 
in the architecture. The multiple interfaces meet the spe- 
cial requirements of network system management. 


@ The Network Application Layer, which defines network 
functions used by the two higher layers. The most im- 
portant DECnet functions currently operating within this 
layer are remote file access, file transfer, and the remote 
terminal capability. 


The Session Control Layer and Network Service Layer, 
which together allow a program in one node to commun- 
icate with a program in another node, via a logical link 
regardless of either program’s location within the 
network. Modules in the User Layer, Network Manage- 
ment Layer, and the Network Application Layer can use 
all the mechanisms provided by the Session Control and 
Network Service Layer. 


© The Transport Layer, which defines an adaptive-path- 
routing mechanism for transporting data from one node 
to a specific node elsewhere in the network over the 
least costly path, as defined by the user. 


@ The Data Link Layer, which defines a mechanism for er- 
ror-free communication between adjacent nodes. The 
layer is independent of communication device charac- 
teristics. 


The Physical Link Layer, which encompasses the soft- 
ware device driver for each communications device plus 
the communications hardware. The hardware includes 
interface devices, modems, and communication lines. 
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DNA specifies the interface by which DECnet softwar 
modules in the same system interact with one another. Re 
flecting the structure of DNA, DECnet modules are lik 
building blocks. Within each node, a layer contains on 
those modules required to support modules in higher la 
ers. 


In addition to defining vertical interfaces, DNA also define 
the protocols governing interaction between modules | 
different nodes. A module in one node communicates on 
with a module in the same layer that is serving the sarr 
function in another node. 


The protocols define the form and content of messages | 
be exchanged by modules. Table 10-1 lists and briefly di 
scribes the function of each DNA protocol. 


Table 10-1 
DNA Protocols 


Proto- 
col 


NICE Network 
Management 


Layer Description 


The Network Informa- 
tion and Control 
Exchange protocol de- 
fines mechanisms for 
exchanging network, 
node, and configura- 
tion data and for ser- 
vicing requests from 
modules residing in the 
Network Management 
Layer. 


DAP Network 
Application 


The Data Access Pro- 
tocol defines mecha- 
nisms for 

performing remote file 
access and remote file 
transfer on behalf of 
software modules re- 
siding in the 

Network Management 
Layer. 


NSP Session Con- 
trol Network 
Services 


The Network Services 
Protocol defines a me- 
chanism for creating 
and maintaining logical 
links between 

modules of higher level 
that reside in the same 
node or different 
nodes. 


Trans- Transport The transport protocol 
port defines a mechanism 
for 
dispatching data to any 
node in the network via 
the best possible route. 


Proto- 
col 


MOP 


Layer Description 


Data Link The Maintenance Op- 
eration Protocol de- 
fines mechanisms for 
transmitting data over 
a communications 
channel to achieve 
specific functions such 
as downline loading of 
a remote node, 

upline dumping froma 
remote node, testing a 
node and network con- 
nections, and starting 
up an 

unattended remote 
node. 


The Digital Data Com- 
munications Message 
Protocol 

defines a mechanism 
for 

ensuring the integrity 
and 

sequentiality of data 
transmitted over a 
communications chan- 
nel. 


DDCMP Data Link 


DNA does not define protocols for all functional layers. For 
example, User Layer programs communicate over the net- 
work according to rules defined by the programmer. 
Furthermore, more than one protocol can be defined for 
the same layer because some layers support more than 
one function. For instance, the Network Application Layer 
can include modules that use the Data Access Protocol 
(DAP) as well as modules that use a protocol defined by 
users for a specific application. 


DECnet COMMUNICATION SOFTWARE 
DECnet-VAX offers Phase Ill networking capabilities that 
provide alternatives for configuration flexibility and com- 
munications cost saving, in addition to Phase Il networking 
features like file transfer and task-to-task communication. 
Adaptive routing reduces the need for direct links between 
every pair of communicating computers in a network. True 
network support tools in the form of Network Management 
are also available with DECnet Phase Ill. Network Com- 
mand Terminals enable users at terminals to access to re- 
mote homogeneous systems as if they were local. 


DECnet-VAX interfaces are standard with VAX/VMS. To 
program task-to-task communication or file access, pro- 
grammers use identical calls whether or not the tasks or 
data are on the same or different systems. The logical link 
between two programs is like an I/O channel over which 
programs can send and receive data. Using DECnet for 
task-to-task communication is like doing I/O with an exist- 
ing driver. 
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Product Capabilities 

The network functions available to the DECnet-VAX user 
depend, in part, on the configuration of the rest of the net- 
work. Each DECnet product offers its own functions and its 
own set of features to the user. Networks consisting en- 
tirely of DECnet Phase III nodes have all the Phase Ill 
capabilities. Networks that combine DECnet-VAX nodes 
with other DECnet products could limit the functions avail- 
able to the DECnet-VAX user because some DECnet-VAX 
features may not be supported by all DECnet products. 
Conversely, the user of another DECnet implementation 
will not necessarily have access to all DECnet-VAX func- 
tions. 


The goal of DECnet-VAX is to provide a network capability 
that is extremely easy to use and that eases the incorpora- 
tion of added processing power when user requirements 
dictate. Task-to-task communication and file access 
between systems is virtually transparent; these intersys- 
tem facilities appear to be no different from the intrasys- 
tem interprocess communication and file access facilities. 
Figure 10-5 summarizes the user/program-level and com- 
munications-level capabilities. Descriptions of the 
functions follow the figure. 
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Figure 10-5 
DECnet-VAX Phase III Capabilities Matrix 


User/Program Level 

Task-to-Task Communication — DECnet-VAX provides 
task-to-task communication, enabling cooperating pro- 
grams to exchange data. Task-to-task communication is a 
method of creating a logical link between two tasks, ex- 
changing data between the tasks, and disconnecting the 
link when the communication is complete. Any VAX lan- 
guage programmer can write programs that perform task- 
to-task communication. 


Intertask communication routines can be coded using one 
of two methods: transparent calls or nontransparent calls. 


With transparent intertask communication the program 
opens the network interchange as if it were preparing fora 
device access. It then performs a series of reads and 


writes just as it would to a pair of serial devices — one for 
input and the other for output. 


Transparent access has no calls specifically associated 
with DECnet software. The calls used for intertask com- 
munication are the same as the calls used for accessing a 
sequential file in a high-level language: OPEN, CLOSE, 
READ, WRITE, etc. The programmer can choose to in- 
clude the target node name in the OPEN statement, or de- 
fer assignment using logical names. 


With nontransparent intertask communication, a program 
can obtain information about the network status to control 
the nature of its communication with other processes or 
tasks. This method of coding intertask communication is 
available to the MACRO programmer. Nontransparent ac- 
cess is available only through calls to operating system 
service procedures. 


The process can send optional data along with the connect 
request. The receiving process or task can accept or reject 
the connect initiate. A process can accept multiple con- 
nect requests. 


A process can send or receive mailbox messages to or 
from another process or task. Mailbox message traffic is 
essentially no different from data message traffic, except 
that it uses a mailbox associated with the I/O channel over 
which the logical link was created. A logical link, therefore, 
has two subchannels over which messages can be trans- 
mitted: one for normal messages and the other for high- 
priority messages. An interrupt message is written to a 
mailbox that a process supplies for that purpose. 


In a DECnet-VAX network, a program using nontranspar- 
ent access normally opens a control path directly to the 
Network Ancillary Control Process (NETACP) and desig- 
nates one or more mailboxes for receiving information 
from the NETACP about the logical or physical links over 
which the process is communicating. 


Access Control — Access control is the method by which 
network users are screened before gaining access to net- 
work facilities. With the appropriate access-control infor- 
mation, a user program can log into a remote system and 
access any of the remote system’s resources. The access- 
ing program must have either an account or access to a 
guest account on the remote system, to log in successfully. 


Remote File Access — All DECnet systems support 
exchange of sequential ASCII or binary files. The DECnet 
software handles compatibility issues among operating 
systems by translating the file syntax of the sending node 
into a common network syntax and then retranslating at 
the receiving end appropriately for that node. The transfer 
of filetypes other than ASCII can also be supported 
between particular operating systems. 


The Remote File Access capability is implemented by such 
features as file transfer, remote command file submis- 
sion/execution, downline taskloading, and terminal-to-ter- 
minal communication. 


DECnet-VAX supports file transfers between locally sup- 
ported File Control Services (FCS) devices and the file 
system of other DECnet nodes. Wildcards can be used for 
the user identification code, filename, filetype, and version 
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number for local-to-remote file transfers. Directory listings 
are also a supported feature. 


Additional facilities available on DECnet-VAX software al- 
low system command files to be submitted to a remote 
node. The list of commands must be in a format accepta- 
ble to the node responsible for the execution. Similarly, 
command files can be received from other systems and 
then executed. 


Downline loading of tasks (programs) and systems is 
another useful tool provided by some DECnet products. 
Downline system loading and it converse, upline system 
dumping, is particularly useful for small memory-based 
RSX-11S systems or for systems in hostile environments. 


Initial task images for DECnet-11S nodes can be stored on 
VAX/VMS file system devices and subsequently loaded 
into remote DECnet-11S nodes. Programs already execut- 
ing on DECnet-11S nodes can be checkpointed to the host 
file system and later restored to main memory in the DEC- 
net-11S node. Overlays for DECnet-11S tasks can also be 
stored on VAX/VMS file system devices. These features 
simplify the operation of network systems that do not have 
mass storage devices. 


For terminal-to-terminal communication, a DECnet-VAX 
utility enables a user to send messages to any VAX sys- 
tem. Messages can be directed to any specific terminal or 
to the operator’s console at the destination node. The 
messages can be exchanged in a dialog. 


Network Command Terminals — With the Network Com- 
mand Terminal facility, local users can log onto and use 
remote VAX systems as though they were local. Network 
Command Terminals, which are a software capability, re- 
quire no special hardware. They provide virtual terminal 
communication between VAX/VMS systems. Intermediate 
nodes can be running DECnet-VAX or other DECnet 
Phase Ill software. 


Network Management — The Network Control Program 
(NCP) performs three primary functions: displaying sta- 
tistical and error information, controlling network compo- 
nents, and testing network operation. These functions can 
be performed locally or executed at remote Phase Ill 
nodes that support these functions. 


An operator can display the status of the DECnet activity at 
any Phase III node in the network. The user can choose to 
display statistics related to the node itself or the communi- 
cation lines, including traffic and error data. The local op- 
erator can also perform many network control functions 
such as starting and stopping lines, activating the local 
node, and downline loading DECnet-11S systems. 


DECnet-VAX provides network event logging to a terminal 
device or disk file. The NCP utility can be used to enable or 
disable the event logging. 


The NCP can also be used to do loopback testing of com- 
ponents of the network. A network manager can send and 
receive test messages over individual lines either between 
nodes or through other controller loopback arrangements. 
The messages can then be compared for possible errors. 
The NCP allows performance of a logical series of tests 
that will aid in isolating network problems. 


Communications Level 

Nodes communicate based on some combination of 
physical and logical capabilities. The physical capabilities 
for DECnet-VAX are point-to-point, multipoint, and adap- 
tive routing. 


Point-to-Point — A point-to-point node communicates 
only with adjacent nodes to which it is directly connected. 


Multipoint — A network party line shares time on one line 
with several nodes. This type of multipoint topology can 
reduce line costs. Multipoint configurations include a con- 
trol station and tributaries. The control station controls 
network traffic by polling; it queries the tributary computer 
station to determine if they have messages to send. 


Routing — Routing is a method for sending messages 
from source to destination through intermediate nodes. 
DECnet Phase Ill provides adaptive routing wherein mes- 
sages are routed through the network over the least-cost 
path, as defined by the user. If either a line or a node in this 
preferred path goes down, the network will automatically 
reroute over the next least-cost-path. 


When a network is brought up or is subsequently under 
user control, line costs are assigned for each line leaving a 
node in the network. Therefore, networks can be tailored 
to make each node’s interactions with other nodes effi- 
cient. The same line can have two different path costs de- 
pending on the direction in which the message is traveling. 


Transparent to the user, this feature enables network man- 
agers to easily reroute traffic, to avoid a troublesome line 
or run diagnostics on such a line. Adaptive routing also 
makes it possible to install backup links, with the result be- 
ing fewer connections than with traditional point-to-point 
networks. 


O—O 


Point-to-Point (physical) 
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Multipoint (physical) 


Routing 


INTERNET PRODUCTS 

DIGITAL’s Internet family of products supports the inter- 
connection of DIGITAL computers and DIGITAL networks 
to systems built by other manufacturers. Internets give 
data processing managers the freedom to choose main- 
frames and minicomputers on the basis of application 
needs, with the assurance that reliable links can be esta- 
blished between systems. 


Internet products emulate common communications pro- 
tocols. They are data transfer facilitators rather than hard- 
ware emulators. While they appear, to other vendors’ 
computers, to be supported devices, they are actually 
parts of powerful DIGITAL systems. They provide trans- 
parent communication with the equipment of other ven- 
dors and, at the same time, offer the flexibility of local file 
systems, many different languages, and a wide selection of 
computing power. 


VAX-11 2780/3780 Emulator 

The VAX-11 2780/3780 protocol emulator provides the 
VAX/VMS user with a mechanism for transferring files 
between a VAX system and another system equipped to 
handle IBM 2780 or 3780 communications protocols. It 
does this by emulating the IBM Binary Synchronous Com- 
munications (BISYNC) protocol used by a 2780 or 3780 
Remote Batch Terminal. 


The emulator can be invoked either interactively or by a 
command procedure. The emulator’s command set is de- 
signed to facilitate sharing a communication line among 
several users. With the appropriate modem options, the 
emulator is capable of automatically answering incoming 
Calls. 


Sophisticated operations can be performed by a combina- 
tion of command procedures — allowing, for example, un- 
attended operation. This would include the capability to 
detect an incoming call, establish the connection, and then 
transmit and receive the files and recover from transmis- 
sion failures — all without intervention from the operator. 


Several data formats are supported with the use of a par- 
ticular format selected by user command. Users can select 
various data format translation schemes. All file 1/O is per- 
formed through the VAX/VMS record-management 
facility. Print and punch stream-recognition is imple- 
mented in such a way that the data manipulation scheme 
can differ with each stream. 


The following remote batch terminal features are sup- 
ported: 

© 2780 Extended and Multiple Record option 

® Variable Horizontal Forms Control 

© BISYNC Transparency 

© 3780 Space Compression 


All of these features are supported on a simultaneous, 
multiline basis. Additionally, the VAX-11 2780/3780 proto- 
col emulator can be used in conjunction with DECnet net- 
works, which means that VAX systems in a DIGITAL net- 
work can also communicate with IBM systems. 


VAX-11 3271 Protocol Emulator 

The VAX-11 3271 protocol emulator provides VAX system 
users with an interactive program-to-program link to an 
IBM mainframe. This emulator enables a user application 
program on a VAX system to exchange data with a pro- 
gram running under CICS or IMS on an IBM host (Sys- 
tem/370). Using two application programs — one for the 
DIGITAL side and one for the IBM side — the VAX system 
user can both send and receive data. 


The user-written program on the VAX system communi- 
cates with the IBM application program by issuing !/O 
requests to the VAX-11 3271 protocol emulator. The emu- 
lator, appearing to the host as an IBM 3271 Model2 Con- 
trol Unit, interacts with the IBM system to perform the 
actual mechanics of the data exchange. It manages the 
protocol and the physical communications in a manner 
that is transparent to the VAX system user. As part of its 
protocol management, it frames the data with appropriate 
BISYNC link-control characters — Start of Text, Unit |den- 
tification, CRC’s, and End Text. 


Application programs that can be used for IBM 3270 (a ter- 
minal without local processing capabilities) operations on 
the VAX system include programs to access IBM data- 
bases and transaction-oriented applications and 
programs to emulate 3270-class terminals. 


The communications discipline used by the VAX-11 3271 
protocol emulator is the 3271 subset of IBM’s Binary Syn- 
chronous Communications (BISYNC) protocol using 
EBCDIC code. Specifically, the subset of BISYNC supports 
operation of full- and half-duplex leased lines in point-to- 
point or multipoint configurations up to 9,600 bits per sec- 
ond. The VAX-11 3271 protocol emulator does not support 
switched facilities, contention line control, or transparent 
BISYNC capability. 


The multidrop BISYNC capability enables the VAX-11 
3271 protocol emulator to coexist with other 3271 controll- 
ers on the same line, thus reducing the number of com- 
munications links. On a VAX-11/780 system, the emulator 
can be connected on up to four IBM systems or can have 
four lines to a single system for higher throughput. On a 
VAX-11/750 system, the emulator supports two lines. 
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The VAX-11 3271 protocol emulator can support up to 32 
logical devices for each “control unit” being emulated. A 
user application program can control one or more logical 
devices. A maximum of 32 user application programs — 
one per logical device — can exist for each control unit. 


In summary, the 3271 protocol emulator performs these 

key activities: 

® Provides all device handling for DUP-11 Synchronous 
line interfaces. 


® Monitors the communication line, via DUP-11 Synchro- 
nous Line Interfaces, for line errors. 

® Performs blocking of user data during transmission. 

® Supports an I/O interface with the user program. 

® Maintains multipoint BISYNC protocol with the IBM host; 
ensures integrity of transmitted and received data; and 
processes polling, selection-addressing sequences, and 
other protocol functions normally handled by an IBM 
3271. 

© Translates incoming data from EBCDIC to ASCII and 
outgoing data from ASCII to EBCDIC. 

® Supports, as an option, a KMS-11 microprocessor that 
enhances performance by providing DMA (Direct Mem- 
ory Access) for the synchronous line adapter. 


MUX200/VAX Multiterminal Emulator 

MUX200/VAX multiterminal emulator is a VAX-based soft- 
ware package that provides communication with a CDC- 
6000 CYBER series or other host computer systems capa- 
ble of using 200 UT mode 4A communications protocols. 


Any VAX interactive terminal can be used to control 
remote job entry or to communicate at command level with 
the host system. Input files can be sent from, and output 
files received onto, any VAX-supported mass storage, unit 
record, or terminal device. 


The MUX200/VAX emulator communicates with the host, 
using the Mode 4A communications protocol (as defined 
in CDC publication 82128000). The software package can 
be configured to support either the ASCII or the external 
BCD versions of the protocol. 


The MUX200/VAX emulator provides for one synchronous 
communication circuit to a host computer system. The 
product supports a single switched or dedicated leased- 
line two- or four-wire common carrier facility at speeds up 
to 9,600 bits per second. 


With the MUX200/VAX emulator, several users can com- 
municate simultaneously with a host system over a single 
line. The VAX/VMS system, though using a single physical 
drop, appears to the host as a number of multidrops and 
terminals on the circuit. 


MUX200/VAX provides the following features: 

® Output received from the host system can be spooled to 
a lineprinter upon detection of a text string predefined 
by the user. 

© Up to eight VAX/VMS fields can be specified for 
transmission to the host in a single command. 

® VAX/VMS terminals can be detached and used else- 
where while the software package is operating. Data re- 
ceived from the host directed to a terminal are saved for 
printing until the terminal is reattached. 


® In many applications the host system can be offloaded 
by taking advantage of the local processing power of a 
VAX/VMS system. This reduces host processing and 
line costs. 


PACKETNET PRODUCTS 


In the 1970s, the International Telephone and Telegraph 
Consultative Committee (CCITT) developed a series of re- 
commendations for standard communication protocols 
that could be used by common carriers to provide data 
communications services. Known as X.25, this recommen- 
dation, which was developed for the public data networks, 
defines the difference between the computer and the net- 
work. The CCITT has also developed a second set of pro- 
tocols (X.3, X.28, and X.29) that specify how to control 
asynchronous terminals connected directly to a network. 
Together, these protocols define the Interactive Terminal 
Interface (ITI). 


The fundamental technology used in public data networks 
is called packet switching. With it, user data and control in- 
formation needed to assure delivery to the correct location 
are formed into discrete entities — packets. The network 
dynamically interleaves the packets of many users over 
shared transmission facilities and routes the packets to 
their destinations. Unlike conventional telephone setups, 
for which the user is charged for both connect time and 
distance regardless of the amount of data passed, charges 
in public data networks are determined so that the person 
who uses the line the most, pays the most. 


X.25 is quickly becoming the standard international com- 
munications protocol. Another advantage is that X.25 al- 
lows computers from different manufacturers to work 
together; with appropriate security validation, any system 
on the network can send data to any other system on the 
network. X.25 ensures data integrity and simultaneously 
relieves users of any concern about input and output 
speeds of the various processors in the network. 


Public data networks are currently operational in the 
United States (the Telenet and Tymnet networks), Canada 
(the Datapac network), France (the Transpac network), 
Germany (the Datex network) and the United Kingdom 
(the PSS network). 


DIGITAL’s Packetnet products provide customers with yet 
another choice for distributing their computing in creative, 
cost-saving ways. Several VAX Packetnet products from 
DIGITAL are now available. X.25 has been integrated into 
Digital Network Architecture, reaffirming the DIGITAL 
commitment to provide customers a choice of interna- 
tional standard approaches to distributed computing. 


VAX-11 PSI 

VAX-11 PSI (Packetnet System Interface) allows a suitably 
configured VAX/VAX system to connect to Public-Packet 
Switched Networks (PPSNs) conforming to the CCITT re- 
commendation X.25. Access to VAX-11 PSI is supported 
for VAX/VMS user programs written in VAX-11 MACRO 
and native-mode high-level languages — for example, 
VAX-11 FORTRAN. VAX-11 PSI supports process-to- 
process and remote terminal communications via the net- 
work. 
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VAX-11 PSI products are now available for use on Public 
X.25 Networks. DIGITAL has so far tested them against 
Telenet, Transpac, Datex-P and PSS, and others are cur- 
rently being tested. Consult your local DIGITAL office for 
the latest list of networks that have been approved. 


For interprocess communication, application programs 
use VAX/VMS System Services to set up and break con- 
nections with the network, to send and receive data, and to 
issue control and synchronization requests. 


To remote terminal users VAX/VMS appears similar to 
that of local terminals — application programs need not be 
aware that access to the terminal is via the VAX-11 PSI 
software. 


User Program Interface 

An interface is provided that allows application programs 
to use the X.25 functions, including setting up and break- 
ing connections, transmitting and receiving data, sending 
and receiving interrupt messages, and resetting virtual cir- 
cuits. This interface, in addition to CCITT X.25 level Ill 
functions, provides the splitting and recombination of 
messages that are longer than the packet size selected for 
the circuit. National extensions, not part of the interna- 
tional recommendations, are not provided. National exten- 
sions do not include, for example, file transfer, file access 
of process addressing. When using this interface, an appli- 
cation program can communicate with any other system 
connected to the network (DIGITAL or non-DIGITAL). This 
interface conforms to the DIGITAL Network Architecture 
specification for X.25 access. 


Interactive Terminal Interface 

VAX-11 PSI supports access by remote terminals accord- 
ing to CCITT recommendations X.3, X.28, and X.29. Termi- 
nals are supported in “Remote X.29 Terminal” mode in 
which code conversions between ASCII and the actual 
code used by the terminal are performed by the network. 
Note that terminals are connected via a Packet Assembly 
Disassembly (PAD) facility provided by the network; no fa- 
cility is offered whereby a terminal connected to a 
VAX/VMS system can act as a network terminal to other 
systems connected to the network. 


The interface presented to an application program using a 
remote X.29 terminal is compatible with that presented to 
a local terminal, except for those facilities where adequate 
support is not provided by the network; for example, the 
support provided by the PAD for data forwarding upon in- 
put of an escape sequence is not compatible with that re- 
quired by DIGITAL standard software. This means that 
FMS and some of the screen editors might not function as 
expected, unless the PAD is set up in a cost-ineffective 
way. Additional facilities are provided that allow a program 
to manipulate the terminal parameters maintained by the 
PAD. 


Network Management 

A system management command interface is provided for 
the control of the operation of the X.25 software. This in- 
cludes loading the software, defining the lines and network 
to which the system is connected, specifying the address- 
ing information for incoming calls, and accessing error 


counters and other maintenance functions. This interface 
provides a subset of the DIGITAL Network Architecture 
specification for Network Management. 


Virtual Circuits 

VAX-11 PSI offers communication over both Permanent 
and Switched Virtual Circuits (PVCs and SVCs), the maxi- 
mum total number of virtual circuits supported being 255. 
The maximum number of remote network terminals sup- 
ported is 64; note however, that each remove terminal 
uses a virtual circuit. Up to two physical connections can 
be made to the PPSN; each line has a unique Data Termi- 
nal Equipment (DTE) address, but each must have the 
same subscription-time options for maximum and default 
packet and window sizes, membership of closed user 
groups, and connect-time facilities. 


Line Discipline 

The communications discipline used is the CCITT recom- 
mendation X.25. Specifically, the product supports V.24 
(EIA - RS232) and V.35 at the hardware level, the symme- 
tric LAPB variant of the X.25 frame level protocol and the 
X.25 packet level protocol over point-to-point four-wire 
synchronous full-duplex lines, at speeds up to 48,000 bits 
per second. 
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Communications 

VAX-11 PSI supports two types of communications inter- 

face: 

® Character interrupt devices with the DUP11 CPU cycles 
are required for X.25 packet and frame level protocol 
processing and also for each character send and re- 
ceived. 


© The KMS11 is a medium-speed Direct Memory Access 
(DMA) Synchronous Communications Interface. Char- 
acter transmission and reception and the X.25 frame 
level protocol (LAPB) processing is executed in micro- 
code by the KMS11 communications controller. The 
VAX-11 CPU then processes only the X.25 packet-level 
protocol. 


Digital's Customer Services organization comprises three groups; Field Ser- 
vice, Software Services and Educational Services. Over 16,000 people in more 
than 400 locations worldwide provide specialized services to assist customers 
before, during and after system installation. This section describes these and 
other groups and the services they offer. 


DIGITAL’s sales force is the primary contact for all products and services. First, 
customers discuss their application requirements and computing needs with a 
DIGITAL sales representative. Then, software and hardware specialists are 
called in to help answer specific questions. These specialists are trained on 
DIGITAL’s products and can suggest alternate solutions for special situations. 


Once a customer’s computing needs are determined, the sales representative 
guides them in selecting a system configuration and reviewing possible site re- 
quirements. This can include adequate floor space, electrical capacity, air con- 
ditioning, and humidity control. Customers can also select a maintenance plan 
that fits their needs and budget. 


Before delivery, a customer’s personnel can be trained under any of DIGITAL’s 
extensive educational programs. Training credits obtained at the time of pur- 
chase can be applied to the cost of some of DIGITAL’s courses. 


Upon delivery, DIGITAL’s Customer Services Personnel are on hand to ensure 
smooth installation. Specialists install the hardware and the software and run 
extensive tests to ensure that the system is correctly installed and performing 
properly. 

Following installation, DIGITAL’s support organizations are available to help 
with any special needs that might arise, both during and after the warranty per- 
iod. Field Service representatives all over the world can provide preventive and 
remedial maintenance to keep system hardware performing optimally. Soft- 
ware specialists are available locally and at centralized units to help answer any 
questions that arise in system operation or use. In addition, software consult- 
ants and the Computer Special Systems group can be contracted to help 
design and build systems to meet individual requirements. 


The purchase of a DIGITAL computer automatically qualifies a customer for 
membership in the Digital Equipment Computer Users Society (DECUS). DE- 
CUS is an independent international organization run entirely by user mem- 
bers. Information about DECUS is contained in this section. 


INSTALLATION 

At system delivery, a Field Service account representative 
will schedule installation of the hardware components. 
During installation, Field Service engineers supervise the 
uncrating and placement of equipment, cable connec- 
tions, and powerup of components. They test the hard- 
ware by running a system exerciser — a complete diag- 
nostic package. Field Service engineers coordinate with 
Software Specialists to install and test the operating sys- 
tem. They use the User Environmental Test Package 
(UETP) to exercise the system software components. This 
package runs compilations and assemblies and serves as 
both a final test of the system and as a demonstration of 
system operation. 


HARDWARE SERVICES 

Onsite warranty begins 30 days after the system was 
shipped or upon customer acceptance, whichever occurs 
first. Hardware components in a packaged system are 
covered under warranty for 90 days. OEMs can buy back 
an installation and 30-day onsite warranty; also an installa- 
tion and day one service agreement is available on a buy 
back basis. During the warranty period, DIGITAL will per- 
form remedial maintenance on any defective components. 


Once the warranty period ceases, a broad range of both 
contract and noncontract maintenance plans is available. 
Contract maintenance plans include DECservice and Ba- 
sic Service. Under either of these contract plans, the cus- 
tomer can benefit from a remote diagnosis option for the 
VAX-11/782, VAX-11/780, and VAX-11/750, and a remote 
support option for the VAX-11/730. Noncontract mainte- 
nance plans include per-cal/ service and offsite service. 
The noncontract plans are the same for all processors. 


Many customers select a DECservice Agreement. The 
DECservice Agreement is for customers who require high 
availability and whose system is critical for daily operation. 
This plan includes alt materials and labor, preventive 
maintenance, and installation of engineering changes. It 
guarantees a defined response on service calls and con- 
tinuous service until repairs are complete. Under the DEC- 
service Agreement, the customer can expand coverage to 
24 hours a day, seven days a week. 


If system availability requirements are not stringent, the 
customer can choose a Basic Agreement. The Basic 
Agreement is for customers with noncritical operations. As 
with DECservice, it includes all materials and labor, and in- 
stallation of engineering changes. Your sales representa- 
tive can advise the best coverage for your operation. 


With both DECservice and Basic Service agreements, 
hardware problems that occur with the VAX-11/780, the 
VAX-11/782, or the VAX-11/750 can be solved quickly with 
DIGITAL‘s Remote Diagnosis (RD). RD provides your sys- 
tem with fast, accurate diagnostic capability from one of 
DIGITAL‘s RD service centers. Since diagnosis typically 
begins within 15 minutes of your service call, and because 
the problem can be quickly isolated to the device level, 
your system‘s availability is maximized. 


In an effort to provide our customers with the best in hard- 
ware service, DIGITAL has introduced a new service fea- 
ture on the VAX-11/730 — Customer Runnable Diagnos- 


tics (CRDs). Under a DECservice or Basic Service 
agreement, customer runnable diagnostics provides a fast 
diagnostic response that maximizes system availability, 
stabilizes maintenance costs, and provides the customer 
with more direct control of the operation. In addition to 
CRDs, Remote Support will also be available to all VAX- 
11/730 contract customers. This service tool provides the 
onsite DIGITAL service engineer with a further level of 
technical support to use when needed. Remote Support 
provides customers with maximum protection against ex- 
tended downtime. 


VAX-11/730 DECservice customers using Remote Sup- 
port have the added benefit of a service innovation called 
Remote Hardware Monitoring (RHM). Under RHM, 
DIGITAL Field Service will set up a schedule with the cus- 
tomer to run periodic remote hardware checks of the sys- 
tem. This program allows DIGITAL to identify potential 
problems and schedule maintenance before a costly 
downtime situation occurs. 


Two noncontract maintenance options are also available. 
Per-call service is provided for customers who do not 
need immediate response or continuous effort. Generally, 
per-call arrangements are useful for installations that are 
noncritical, have redundant backup equipment, or are 
self-maintained. Per-call service is also offered as a sup- 
plementary service (on a “best efforts” basis) for service 
agreement customers, if remedial service is required out- 
side the hours of contract coverage. 


Offsite Services are available for customers who prefer to 
maintain their own equipment. DIGITAL offers many kinds 
of assistance, including offsite repair of major equipment 
and modules; recommended spares service, spare parts, 
tool kits, and test equipment; maintenance documentation 
and engineering updates; emergency parts service; and 
hardware maintenance training. 


SOFTWARE SERVICES 

Software Services is committed to maintaining a high level 
of support for the VAX/VMS software products. Software 
specialists well-versed in VAX/VMS software can provide 
expert Knowledge and experience necessary to analyze 
the customer’s needs, identify those DIGITAL services that 
will help meet those needs, and deliver those services 
through DIGITAL’s local office. Local Software Specialists 
have access to backup support groups at the regional and 
corporate levels so that DIGITAL’s total software resources 
and expertise are available to support VAX/VMS software. 


Software Warranty 

VAX/VMS software is a DIGITAL-supported product. A 
DIGITAL-supported software product is engineered ac- 
cording to corporate quality standards, operates in accor- 
dance with a Software Product Description (SPD), and car- 
ries DIGITAL’s commitment to provide support services, 
as defined in the Software Support Categories Addendum, 
for the product. VAX/VMS is a DIGITAL-installed product 
that must be installed by an authorized DIGITAL represen- 
tative, in order to qualify for software support. 


DIGITAL-supported software products receive a 90-day 
warranty period, following installation. If, during the 90 
days of warranty, a problem with the software is encoun- 
tered that DIGITAL determines to be caused by a defect in 


the current unaltered release of the software, DIGITAL will 
provide the following remedial services, on site where 
necessary. If the software is inoperable, DIGITAL will apply 
a temporary correction or make a reasonable attempt to 
develop an emergency bypass. 


After the initial purchase of a DIGITAL-supported product 
license, additional copies can be purchased as DIGITAL- 
supported or as a Customer-supported license-to-copy. 


SOFTWARE PRODUCT SERVICES (SPS) 

To ensure continued software support and maintenance 

after the warranty period, Software Product Services pro- 

vide one of the most comprehensive system support ser- 
vices in the industry. The family of services includes three 
contractual levels: DECsupport Service for Software, Basic 

Service for Software, and Self-Maintenance Service for 

Software. Software Product Updates are also available. 

e Self-Maintenance Service — This service includes 
VAX/VMS Software Product and Documentation Up- 
dates and a periodic newsletter that provides up-to-date 
information on new software developments and pro- 
gramming enhancements. 


e Basic Service — All the elements of Self-Maintenance 
Service for Software are included, plus telephone sup- 
port for fast response to software usage and remedial 
questions. In addition, machine-readable Program 
Change Orders are sent automatically upon release. 


e DECsupport — This service is the most comprehensive 
service offered. It incorporates all those services in- 
cluded in the Basic Service, plus the services of a soft- 
ware specialist to deliver and install Updates and Pro- 
gram Change Orders. Onsite remedial support is also 
included for critical situations. 


Additionally, VAX/VMS SPS users may utilize the Soft- 
ware Performance Report (SPR) communication chan- 
nel for suggestions and non-critical problems. 


e Software Product Updates —These consist of Software 
Updates on the customer's choice of available media 
and the most recent documentation. Support services 
are provided upon request at additional cost. 


PROFESSIONAL SERVICES 

Whenever expert software assistance is needed, 
DIGITAL’s software consultants are available. These soft- 
ware specialists are experienced designers and writers of 
custom software who can tailor DIGITAL software to spe- 
cific needs. Their expertise can be applied to any phase of 
an application project, from analysis through implementa- 
tion. 


Software specialist services are available on a resident, 

per-call, or a fixed-price, per-project basis: 

e Resident service is for customers who need full-time on- 
site support. Resident consultants are particularly useful 
in new complex installations or for critical longterm pro- 
jects. Residents are available for a minimum of six 
months; arrangements can be made to extend the 
length of service to suit individual needs. 


Per-call service is for customers with irregular or infre- 
quent consulting needs. Per-call (hourly) services are 
ordered as needed for short-term projects, and gener- 
ally extend from a few days to a few weeks. 


e Software personnel can be assigned to projects based 
upon the schedule and resource requirements neces- 
sary for a customer’s success. 


For detailed information on DIGITAL’s software services, 
contact the local DIGITAL sales office. 


EDUCATIONAL SERVICES 

DIGITAL provides comprehensive educational programs 
to train a customer’s personnel before, during, and after 
installation. These programs offer specific job-related 
courses that effectively increase productivity. Instruction in 
system management, operations, hardware, and software 
is given by trained instructors at DIGITAL’s 26 Training 
Centers worldwide. In addition to Lecture Lab, a variety of 
other training formats is available — Selfpaced Instruction 
(SPI), Onsite Training, Exclusives, and Manage- 
ment/Technical Seminars. 


Courses fall into the following general categories: 

e General Computer Courses — These are not geared to a 
specific DIGITAL system or product, but provide a 
technical foundation for personnel who have little com- 
puter experience. 


e Software System Courses — These courses are de- 
signed to train users, programmers, and operators in 
the efficient and knowledgeable use of DIGITAL’s oper- 
ating systems, languages, and utilities. Courses are 
available for both beginning and advanced users. These 
courses assume that the student has general computer 
and programming knowledge. 


e Hardware Courses — These are designed for customers 
who intend to service their own equipment or who sim- 
ply want a general understanding of the components in 
their system. Courses are available in general hardware 
familiarization, hardware troubleshooting, and hardware 
maintenance. 


There is a choice of training formats: 

e Lecture/Lab Instruction — This format provides tradi- 
tional classroom lectures and laboratory experience at 
one of DIGITAL’s 26 worldwide Training Centers. Stu- 
dents benefit from the experience and individual 
attention of professional instructors, interaction with 
other students, and access to well-equipped computer 
labs. 


e Sel/fpaced Instruction (SPI) — Selfpaced courses offer 
training materials that are portable, selfcontained, and 
modular in format. They are educationally designed so 
that students can progress at their own rates. SPI can be 
scheduled around peak working hours or wherever and 
whenever study is possible. For convenience, SPI 
courses are offered in three forms: print (using text- 
books or manuals); audiovisual (cassettes and film- 
strips); and computer-based instruction (taught on the 
computer by the computer). 


e Onsite Training — Every lecture/lab course offered by 


Educational Services can also be taught at the cus- 
tomer’s job site. Onsite courses can be adapted to cover 
particular application needs or operational needs in 
depth. 


® Exclusive Courses — If customers have a unique appli- 
cation, Educational Services can create an exclusive 
course tailored to their needs and schedule. The 
courses can be completely new or can be modifications 
of existing Courses. 


Technical and Management Seminars — Management 
seminars are specifically designed for the nontechnical 
users to better understand data processing and how 
best to utilize its capabilities. These seminars are in- 
tended for all levels of supervisory, middle, and upper 
management. Technical seminars are a series of state- 
of-the-art programs aimed at data processing profes- 
sionals and managers; they focus on the newest applied 
technologies. 


VAX Courses 

DIGITAL’s Educational Services offers a comprehensive 
series of courses to provide specific VAX training for all 
levels of users. These courses range from introductory 
material that describes the fundamentals of the VAX sys- 
tem hardware and software to advanced courses designed 
for systems programmers. The diagram below illustrates a 
typical curriculum for VAX users: the system manager, 
system programmers, applications programmer, and op- 
erator. 


Following are brief descriptions of the courses shown in- 
Figure 11-1. 


Introduction to Minicomputers: |Introduces Computer sys- 
tem concepts, peripherals, and memory principles. 


Commercial Programming Concepts: Introduces 
commercial computer concepts and data processing prin- 
ciples, including basic commercial programming tech- 
niques, the fundamentals of programming, and table and 
array handling. 


VAX-11 Concepts: Introduces VAX-11 concepts, terminol- 
ogy, and hardware and software components. Includes 
hexadecimal arithmetic and conversions and a description 
of VAX-11 data representation. 


VAX-171 Instruction Set: Introduces addressing modes, 
arithmetic operations, string techniques, and the use and 
coding of VAX-11 instructions. 


VAX/VMS Utilities and Commands: Teaches how to per- 
form nonprivileged user tasks under the VAX/VMS oper- 
ating system. The course covers the commands and pro- 
cedures required to develop and run programs in both 
interactive and batch environments. 


VAX/VMS System Management: Presents the routine op- 
erating procedures that a system manager performs on 
behalf of the system users. 
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Assembly Language Programming in VAX-11 MACRO: 
Teaches entry-level programmers how to write VAX-11 
MACRO assembly language programs. It also discusses 
the use of VAX-11 Record Management Services (RMS) in 
performing sequential file access. 


Programming in FORTRAN IV: Teaches how to program in 
FORTRAN IV with a careful study of the syntax, format, and 
structure of the language. 


BLISS Primer: Presents a generic course covering all 
DIGITAL systems that support the BLISS language. 


Programming in PDP-11 COBOL: Teaches how to pro- 
gram in PDP-11 COBOL and includes a careful study of 
the syntax, format and structure of the language. 


Programming in BASIC-PLUS-2: Presents a generic 
course including syntax and the capabilities of the lan- 
guage. 

Programming VMS in VAX-11 FORTRAN/MACRO: 
Teaches how to use the system services and the Runtime 
Library of VMS, using the VAX-11 MACRO and VAX-11 
FORTRAN languages. 


Programming VMS in VAX-11 COBOL: Teaches applica- 
tion programmers to use the system-dependent features 
of the VAX/VMS operating system with the VAX-11 CO- 
BOL programming language. 


Programming VMS in VAX-11 BASIC: Teaches advanced 
VAX-11 BASIC application programmers how to use the 
system features of VAX-11 BASIC. 


VAX/VMS Operating System Internals: Provides an exten- 
sive understanding of the various components, data struc- 
tures, and operations of the VAX/VMS operating system. 


VAX/VMS DECnet User: Prepares programmers and sys- 
tem managers to install, use, and monitor DECnet on 
VAX/VMS systems. Considerable emphasis is placed on 
interfacing with the Network Control Program (NCP), de- 
fining the user interface, effecting intertask communica- 
tion, and understanding the relationships among the vari- 
ous system components. 


VAX/VMS Device Driver: Teaches the techniques for 
writing and incorporating a device driver into the VMS op- 
erating system. 


Additional information concerning course content and 
availability of training credits can be obtained from your 
sales representative. 


DIGEST 

DIGEST, a quarterly publication of Educational Services, 
contains a complete schedule of all general and software 
courses offered at the North American Training Centers. 
To receive a DIGEST contact the nearest Educational Ser- 
vices Training Center. Consult a DIGITAL sales represen- 
tative for more specific information about when to con- 
sider, order, or use DIGITAL’s training programs. 


Digital Press 

Digital Press publishes books and college texts on a wide 
range of computing issues and topics. They develop 
books in the areas of computer technology, management 
and business applications, computing history, and general 
applications. 


Computer Special Systems 

DIGITAL’s Computer Special Systems (CSS) group pro- 
vides solutions for special needs. Customers can contract 
this group — which includes analysts, engineers, pro- 
grammers, and manufacturing specialists — to obtain 
hardware and software tailored to their application. 


CSS builds hardware, software, and system components 
that supplement DIGITAL’s standard product mix. Prod- 
ucts and systems are analyzed, designed, and imple- 
mented according to a customer’s goals and require- 
ments; they can range from simple processor interfaces to 
complete turnkey hardware and software systems. CSS 
services are available on a fixed-price contract basis. 

e Special hardware — CSS interfaces DIGITAL hardware 
with that of other manufacturers; modifies standard 
hardware, and designs and builds new equipment. All 
special hardware can be manufactured in any quantity; 
spares and support are guaranteed. 


Special Software — CSS designs and produces diag- 
nostic, systems and applications software. They modify 
and expand standard DIGITAL software systems or 
build new software according to your needs. When re- 
quired, CSS will supply software on a turnkey basis. 


Special Systems — CSS will build complete hardware 
and software solutions for a customer’s special applica- 
tion. CSS project managers oversee the analysis, de- 
sign, and implementation of the system. They work with 
the customer to ensure proper installation and startup. 


Support — CSS solutions receive DIGITAL’s standard 
support. Hardware is supported by DIGITAL’s extensive 
Field Service organization, and training is available on 
allaspects of CSS systems. 


For information on how to take advantage of the services 
provided by CSS, contact a DIGITAL sales representative. 


CUSTOMER FINANCING 

To simplify the financial problems in acquiring a new com- 
puter, DIGITAL provides leasing and financial counseling. 
The Customer Finance Department is organized to help 
customers acquire a DIGITAL system using a lease, condi- 
tional sale, or similar financing agreement, rather than an 
outright cash purchase. 


For private organizations or commercial businesses, 
DIGITAL has developed a program known as DIGITAL 
Leasing with the U.S. Leasing Corporation of San Fran- 
cisco. DIGITAL Leasing is a division of U.S. Leasing that’s 
committed solely to the financing of DIGITAL‘s computers. 
Representatives are located in or near many of the 
DIGITAL District Sales Offices. 


Federal, state, and local government agencies have spe- 
cial contractual need and, in some cases, can benefit from 
special tax privileges. For example, a state or municipal 
agency qualifies for special interest rates on Conditional 
Sales Agreements that are significantly below those 
charged to commercial customers; the interest income is 
free from federal and, in some cases, state income taxes. 


The following three types of financing are available: Full 
Payout Lease, Conditional Sales Agreement, and Federal 
Government Lease to Ownership Agreement. 


© Full Payout Lease — This financing is used primarily by 
commercial customers. It involves a noncancelable, 
three-to-seven-year term, usually with a ten-percent 
purchase option at the end. No down payment is re- 
quired, and title remains with the lessor. Lease payment 
schedules are flexible and can be tailored to the cus- 
tomer‘s needs. 

® Conditional Sales Agreement — This type of financing is 
used primarily by nonprofit institutions and state and lo- 
cal governments. It also involves a noncancelable, 
three-to-seven-year term. Title passes to the customer, 
but DIGITAL retains a security interest. The customer 
owns the equipment free and clear at the end of the 
term. Fiscal funding provisions are available for state 
and local governments. 


© Federal Government Lease to Ownership Agreement — 
This financing is available only to approved federal gov- 
ernment agencies. It involves a three-to-five-year term, 
cancelable at the end of each fiscal year and at the gov- 
ernment’s convenience. Ownership passes to the cus- 
tomer at the end of the term. 


DIGITAL’s customer financing group can provide financial 
counseling to help decide which arrangement is best. For 
more information, contact a DIGITAL sales representative. 


CUSTOMER SPARES 

DIGITAL’s Customer Spares group supports customers 
who choose to perform their own computer maintenance. 
Customer Spares services include spares inventory plan- 
ning; maintenance documentation service; spares, tools, 
and test equipment; and spares kits. To assist customers 
in establishing proper spares inventories for computer 
maintenance, Customer Spares provides well-defined 
spares kits and a recommended spares list for individual 
devices or entire systems. Maintenance documentation, 
available by subscription, includes all standard documents 
(excluding engineering drawings) used in the maintenance 
of DIGITAL’s hardware. 


Spares specialists located at many of the DIGITAL district 
offices can assist customers in selecting and maintaining 
proper spares inventories. Contact your local DIGITAL 
sales office for more information and for literature that fur- 
ther describes Customer Spares products and services. 


COMPUTER SUPPLIES 

DIGITAL’s Computer Supplies group offers a wide range 

of compatible accessories and supplies items, including: 

® Magnetic media for all VAX-compatible disks and tape 
drives. 

® Options and accessories for all hardcopy and video ter- 
minals. 

® VAX documentation library. 

e System expansion units, such as equipment racks, sto- 
rage cabinets, and interface cables. 


Supplies specialists, who are located at many DIGITAL 
district offices, can help plan a customers supply needs. 
Contact your local sales office for more information. 


DECUS 

Digital Equipment Computer Users Society is one of the 
largest most active user groups in the computer industry. 
It is not-for-profit organization supported in part by 
DIGITAL, but actively directed by individuals who have 
purchased, leased, ordered, or use a DIGITAL computer, 
or have a bonafide interest in DECUS. 


The objectives of the Society are to: 

® Advance the effective utilization of computers, compo- 
nents, systems, and software manufactured and 
marketed by DIGITAL by promoting, in a non-commer- 
cial manner, the interchange of information concerning 
their use. 

© Advance the art of computation through mutual educa- 
tion and exchange of ideas and information. 

® Establish standards and provide channels to facilitate 
the exchange of computer programs among DECUS 
members. 


® Provide feedback to DIGITAL on equipment and soft- 
ware needs. 


© Reduce the duplication of development efforts. 


DECUS Structure 

DECUS is a federation of geographically based chapters, 
each administered by an elected Executive Board, a 
DIGITAL Representative and an Executive Director. 


This structure provides DECUS Services on a local level to 
its membership. The following are the current DECUS 
Chapters and the countries served by each: 


DECUS U.S. DECUS Canada 
One Iron Way P.O. Box 13000 
MR2-3/E55 Kanata, Ontario 
Marlboro, MA 01752 K2K 2A6 
Phone:(617)467-4100 CANADA 


Phone:(613)592-5111 
Extension: 2115 


DECUS Japan 
Sunshine 60 

P.O. Box 1135 

1-1 Higashi 
Ikebukuro-chrome 
Toshima-ku 
Tokyo 170 


DECUS Australia 

P.O. Box 384 
Chatswood, NSW 2067 
Australia 
Phone:(61)2412-5237 


DECUS Europe 

12 Ave des Morgines 
C.P.510 

1213 Petit-Lancy 1/GE 
Switzerland 
Phone:(022)93-33-11 


Countries Served: 
Europe, Middle East, 
North Africa, Russia 


Countries Served: 
Australia, New Zealand 
Singapore, Indonesia, 
PNG, Malaysia 
Combined membership in DECUS has reached 50,000 in 
January 1982. All DECUS products and services are avail- 
able to DECUS members only. 


Membership is free and voluntary. 
All members are invited to take an active interest in the So- 


ciety by contributing to the Program Library, to chapter 
newsletters and by participating in its Special Users 
Groups and symposia. 


There are two types of membership - Installation Member- 
ship and Associate Membership. An organization, institu- 
tion, or individual who has purchased, leased, or has on 
order a computer manufactured by Digital Equipment Cor- 
poration is eligible for Installation Membership in DECUS. 
Membership status is acquired by submitting a written 
application to the appropriate Chapter Administrator for 
approval by the Chapter Executive Board. Any person who 
is not an appointed Installation Delegate and who has a 
bona fide interest in DECUS is eligible for Associate Mem- 
bership. 


To further the goals of the society, DECUS serves its mem- 
bers by holding symposia; maintaing a program library; 
publishing a society newsletter, technical newsletters and 
books; and supporting a number of subgroups for special 
interest and locations. 

Symposia — 

One of the major activities of the society is the symposia 
that are held throughout the year in each of the DECUS 
Chapters. These meetings provide an opportunity for 
users of DIGITAL computers to meet with other users and 
with DIGITAL management, engineers and customer ser- 
vice representatives. They provide a forum for users to ex- 
change information on techniques and approaches to is- 
sues of common interest and to provide feedback to 
DIGITAL on existing and future products and services. 
Sessions at symposia include user-driven workshops, tu- 
torials, product panels, as well as application/system-spe- 
cific presentations. The technical papers and presenta- 
tions from each symposium are published as DECUS 
Proceedings. 


Two symposia are held each year in the U.S. Chapter and 
one is held in each of the other four chapters. 


Program Library — 

Another important activity of the Society is the DECUS 
Program Library. The Library contains programs written 
and submitted by users and is maintained and operated as 
a clearing-house for user-contributed programs and doc- 
uments. A wide range of software is available, including 
languages, editors, numerical functions, utilities, display 
routines, and various other types of application software. 


Library catalogs are published for PDP-8, PDP-11/VAX, 
and DECsystem-10/20 programs. They are updated yearly 
and contain descriptive abstracts and ordering informa- 
tion. Submission standards must be met before programs 
are accepted into the Library. Review procedures are en- 
couraged to determine whether the program remains in 
the Library, is changed, or removed. Programs are avail- 
able to all members on a request basis. Information on the 
nominal service charge applied to the programs and docu- 
mentation is published in the Library Catalogs. As of Janu- 
ary 1981, the Library contained approximately 1,700 active 
Software Packages. A Library Catalog can be obtained by 
contacting your nearest DECUS Chapter Office. 


Publications — 

DECUS publishes society newsletters for each of its 
chapters. Society members are invited to submit ideas, 
programming notes, and letters. 


The ‘Proceedings of the Digital Equipment Computer 
Users Society” contains papers presented at each of the 
DECUS symposia. The Proceedings are published after 
each symposium and are sent automatically to symposium 
attendees. Others can purchase Proceedings on a single 
copy basis, or by subscription for the five Proceedings 
published annually, by submitting a purchase order to DE- 
CUS. The DECsystem-10/20 Group publishes biannual re- 
ports of its sessions at the two U.S. symposia. All Proceed- 
ings detail information on the work being done in areas of 
software, hardware, and applications by many members of 
DECUS. 


Single copies or complete sets of the DECUS symposia 
Proceedings can be obtained by submitting a purchase or- 
der to the nearest DECUS Chapter Office. It will provide 
price and shipping information for the Proceedings on re- 
quest. 


Special User Groups — 

DECUS encourages users with common interests and/or 
geographical proximity to organize subgroups to meet 
their individual needs. To this end, two basic categories of 
Special User Groups exist. 


Special Interest Groups (SIGs) — 

These groups, organized around a common user interest, 
promote the interchange of specialized information and 
have no geographical limitations. Areas of specialization 
can include application concepts, subject areas (such as 
languages), or specific operating systems. A group of 
users must petition the Chapter executive Board for re- 
cognition as a Special Interest Group. The group must 
have a chairperson and its organization must meet the 
guidelines set by the Chapter Executive Board. SIG mem- 
bers derive numerous benefits from communicating with 
others who share specialized interests and experiences. 
SIGs sponsor business meetings, tutorial and workshops 
at DECUS Symposia. SIG members carncontribute to 
newletters, which most SIGs publish and disttibute to their 
members, participate in SIG sessions and Symposia Re- 
view Committees, and serve as reviewers of programs 
submitted to the DECUS Library. 


Local User Groups (LUGs) — 

These groups provide people who use DIGITAL’s products 
and share a common interest, geographical area and/or 
language an opportunity to exchange hardware and soft- 
ware ideas. Each Local User Group is assigned a repre- 
sentative from the local DIGITAL Sales Offices. It is the re- 
presentative’s responsibility to keep the respective LUG 
fully informed concerning new products and versions. The 
representative will be requested to assist in locating 
speakers for LUG meetings. Generally, the speaker will be 
obtained from Software Services and/or Field Services. 
While each LUG is organized differently, they all share an 
interest in the effective use and support of their DIGITAL 
computer. 
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CR11 cardreader, 5-3 


CRDs (Customer Runnable 
Diagnostics), 11-1 


CREATE command, 8-12 
CREATE/FDL utility, 9-5 
CROSS operator, 9-14, 9-16 


cross-reference listings 
in VAX-11 FORTRAN, 7-6 
in VAX-11 PASCAL, 7-25 


CSRs (control/status registers), 4-24 
to 4-25, 4-37, 5-1 


CSS (Computer Special 
Systems), 11-4 


Current Frame register, 4-8 
customer financing, 11-4 to 11-5 


Customer Runnable Diagnostics 
(CRDs), 11-1 


Customer Spares, 11-5 


Cyclic Redundancy Check (CRC) 
instruction, 4-15 


D 


Data 
integrity of, 2-3 
protection codes for, 3-8 
types of, 4-1 to 4-4 


database management, 9-1 


Database Management System 
(DBMS), 2-4, 9-6, 9-16 to 9-19 


Database Management System 
(DBMS) 
in VAX-11 COBOL, 7-8 


Database Operator (DBO), 9-19 


data communication facilities, 2-1, 
10-1 to 10-10 


data definitions, 9-14 to 9-15, 9-17 
data inquiry, 9-1 

Data Link Layer (DNA), 10-2 

data management, 9-1, 9-15 


Data Manipulation Language (DML) 
in FORTRAN, 9-18 
in VAX-11 COBOL, 7-8, 7-11, 9-18 


data paths, 4-37 
data registers, 4-24 to 4-25 
data retrieval, 9-15 


Data Terminal Equipment (DTE), 
10-8 


DATATRIEVE, 2-4, 9-5, 9-6, 9-13 to 
9-16 
datatypes, 4-1 to 4-4 


data types 
key field, 9-10 
in VAX-11 BASIC, 7-15 
in VAX-11C, 7-20 
in VAX-11 COBOL, 7-9 
data update, 9-1 


DBMS, see Database Management 
System 


DBO (Database Operator), 9-19 
DBO/VERIFY utility, 9-19 


DBQ (database query interface), 
9-18 


DB statement, 7-11 


DCL, see VAX/VMS command 
language 
debugger (Interactive Symbolic 
Debugger), 2-4, 7-1, 8-7 
debugging, 7-1 
in VAX-11 BLISS-32 7-31 
in VAX-11C, 7-12 
in VAX-11 COBOL, 7-9, 7-12 
in VAX-11 FORTRAN, 7-8 


DEC/CMS (Digital Equipment 
Corporation Code Management 
System), 8-11 to 8-12 


declarations, in VAX-11 BASIC, 7-15 


DECLARE statement 
in DATATRIEVE, 9-14 
in VAX-11 BASIC, 7-15 
in VAX-11 PL/I, 7-27 


DECnet, 10-3 to 10-5 


DECnet 
DIGITAL Network Architecture 
for, 10-2 


DECnet-VAX, 2-2, 10-3 to 10-5 
DECservice, 11-1 
DECsupport, 11-2 


DECUS (Digital Equipment Computer 
Users Society), 11-5 to 11-6 


DECwriter Ill terminal, 5-3 to 5-4 
DECwriter IV terminal, 5-4 
DEFINE statement, 9-14 
detached processes, 6-3 

device drivers, 6-24, 6-25, 9-1 
device names, 6-14, 9-2 

devices, see hardware; peripherals 
diagnostic message, 7-6 


diagnostics, 2-3 
hardware services for, 11-1 
online, 3-10 
remote, 2-4, 3-10, 4-31 
User Environment Test Package 
for, 3-11 
See also debugging 


Dictionary Management Utility 
(DMU), 9-16 


DIFFERENCES utility, 8-10 to 8-11 
DIGEST, 11-4 


DIGITAL command language, see 
VAX/VMS command language 


Digital Equipment Computer User 
Society (DECUS), 11-5 to 11-6 


Digital Equipment Corporation Code 
Management System 
(DEC/CMS), 8-11 to 8-12 


DIGITAL Network Architecture 
(DNA), 10-2 to 10-3 


Digital Press, 11-4 
Direct Data Path, 4-29 


directives 
in MACRO-11, 7-34 
in VAX-11 MACRO, 7-33 


direct memory access (DMA), 4-35, 
5-1 


directories, 3-8, 9-2 
directory names, 3-8 
desk files, 9-1 
disks, 5-1 to 5-2 


disks 
RLO2, 4-39 


displacement-deferred mode, 4-6 
displacement mode, 4-6 


distributed computing networks, 
10-1 

DMA (direct memory access), 4-35, 
5-1 

DMC11, 5-7 

DMF32 controller, 4-39, 5-5 


DML, see Data Manipulation 
Language 


DMP11, 5-7 


DMU (Dictionary Management 
Utility), 9-16 


DNA (DIGITAL Network 
Architecture), 10-2 to 10-3 


document formatter (RUNOFF), 8-7 
to 8-8 


DR11-B, 5-6 
DR780, 5-6 


DTE (Data Terminal Equipment), 
10-8 


dynamic access, 9-9 
DZ11 terminal line interface, 5-5 


E 


ECC, see Error-Correcting Code 
EDIT/FDL utility, 9-5 

editors, 8-1 to 8-4 

Edit statement, 9-14 

EDT editor, 8-1 to 8-2 

educational services, 11-2 to 11-4 
emulators, 10-5 to 10-7 


entry point vectors, 8-5 to 8-6 
Error-Correcting Code (ECC), 2-1 
in VAX-11/730, 4-38 to 4-39 
in VAX-11/750, 4-34 
in VAX-11/780, 4-28 
error messages 
in VAX-11 BLISS-32, 7-31 
see also debugging 
errors 
Common Runtime Procedure 
Library 
handling of, 8-6, 8-7 
as exception conditions, 6-15 
logging of, 2-3, 3-10 
tracebacks for, 7-1 
VAX-11 BASIC handling of, 7-17 
VAX-11 PASCAL handling of, 7-25 


EVALUATE statement, 7-8, 7-9 


event flags 
common 6-16 
local 6-14 


events, system, 6-21 
exact key match, 9-11 
exception dispatcher, 6-2 
exception handers, 6-15 
exceptions, 4-4, 4-8, 4-22, 6-15 
exceptions 
in compatibility mode, 4-16 
condition-handling facility for, 7-1 
executable images, 8-4 
expressions, in VAX-11 PL/I, 7-27 
external functions, 7-6 
Extract Field instructions, 4-12 


F 


fault detection, 2-3 

faulthandling, 4-31 to 4-32 

faults, page, 6-19 to 6-20 

FCS (File Control Services), 10-4 
FDL (File Definition Language), 9-5 
File Control Services (FCS), 10-4 
File Definition Language (FDL), 9-5 
file directories, 9-2 

file |/O interface, 9-22 


files 

attributes of, 9-9 to 9-10 

compatibility mode and, 6-26 

DIFFERENCES utility for, 8-10 to 
8-11 

as linker input, 8-4 

management of, 9-1 to 9-5 

names and types of, 8-1 

protection for, 3-8 

remote access to, 10-4 

RMS, program operations on, 9-10 
to 9-12 

RMS organization of, 9-6 to 9-7 

for SLP editor, 8-3 to 8-4 


VAX-11 BASIC manipulation of, 
7-16 
VAX-11 COBOL manipulation 
of, 7-11 to 7-12 
VAX-11 FORTRAN manipulation 
of, 7-5 
Files-11 On-Disk Structure Level 2 
(ODS-2), 2-2 
file specifications, 9-2 to 9-3 
filesystem, 9-1 
filing (in RUNOFF), 8-8 
financing, 11-4 to 11-5 
FIND statement, 9-14 
fixed-length record format, 9-9 
fix-up image section, 8-5 
flags 
common event, 6-16 
local event, 6-14 
flexibility, 2-4 to 2-5 
floating-point accelerator (FPA), 2-2 
to 2-3 
in VAX-11/730, 4-40 
in VAX-11/750, 4-34 
in VAX-11/780, 4-29 
in VAX-11/782, 4-32 
floating-point data, 4-2 
floating-point instructions, 4-9 to 
4-11 
floppy disk cartridges, 5-7 
FMS (Forms Management System), 
2-4, 9-6, 9-19 to 9-21 
formatter (RUNOFF), 8-7 to 8-8 
forms 
in DATATRIEVE, 9-15 
FMS for, 2-4, 9-6, 9-19 to 9-21 
Forms Management System 
(FMS), 2-4, 9-6, 9-19 to 
9-21 
FOR statement, 9-14 
FORTRAN, VAX-11, 3-5, 7-2 to 7-8 
FORTRAN IV (PDP-11), VAX to 
RSX, 3-6, 6-25, 7-33 to 7-34 
FORTRAN-77, 3-5, 7-2 
FORTRAN DML, 9-18 
FP (Frame Pointer), 4-5 to 4-8 
FPA, see floating-point accelerator 
Frame Pointer (FP), 4-5 to 4-8 


functions 
mathematical, 8-6 
VAX-11 FORTRAN calls for, 7-6 
in VAX-11 PL/I, 7-27 


G 


general registers, 4-5 to 4-8 


general registers 
instructions for manipulation of, 
4-13 
PDP-11, in compatibility mode, 
4-15 


general utility (LIBS), 8-6 

generic key match, 9-11 

global sections, 6-17 

graphics, in DATATRIEVE, 9-15 

groups (jobs), 6-3, 6-4 

groups (user), 3-8, 6-4 

G (general-Purpose) subset of 
PL/I, 7-26 to 7-27 

Guide Mode, 9-15 


H 


HALT instruction, 4-15 


hardware 

interrupts generated by, 4-24 

support services for, 11-1 

in VAX-11/750 processor, 4-33 to 
4-35 

in VAX-11/780 processor, 4-27 to 
4-28 

in VAX-11/782 attached processor 
systems, 4-30 to 4-31 

see also peripherals 


hardware context, 4-16 

hardware process-control block, 
4-25 

HELP facilities, 2-4 
in EDT editor, 8-1 
in FMS, 9-20 

help libraries, 8-8 

HELP statement, in DATATRIEVE, 
9-14 

Hibernate system service, 6-16 


HOST/TERMINAL 
SYNCHRONIZATION, 5-3 


IDC (Integrated Disk Controller), 
4-39 to 4-40 


image map files, 8-4 
images, 4-1, 6-3 
in Common Runtime Procedure 
Library, 8-5 to 8-6 
known, 3-9, 6-4 
as linker output, 8-4, 8-5 


image section descriptors (ISDs), 8-5 


image sections, 8-5 


immediate (autoincrement) mode, 
4-6, 4-7 


INCLUDE statement, 7-6 
indexed addressing modes, 4-6 
indexed file organization, 9-7 


indexed file organization, 
access modes to, 9-8 
I/O processing of, 9-11 
key definitions for, 9-10 


Indexed Sequential Access Method 
(ISAM), 7-5 


indexes, RUNOFF creation of, 8-8 
Index instruction, 4-12 
index registers, 4-6 
index sorts, 9-21 
information management 
facilities, 2-1, 9-1 to 9-22 
INSERT command, 8-12 
installation, 11-1 
instruction buffers, 4-28, 4-35, 4-39 
instructions and instruction sets, 4-1 
instructions and instruction sets 
for floating-point accelerator, 2-2 
to 2-3, 4-29, 4-32, 4-34, 
4-40 
native, 4-8 to 4-15 
PDP-11 Instruction Set, 4-16 
protected and privileged, 4-18 
integer data, 4-2 
integer instructions, 4-9 to 4-11 


Integrated Disk Controller (IDC), 
4-39 to 4-40 


Interactive Symbolic Debugger, 
2-4, 7-1, 8-7 

interactive symbolic debugger 
see also debugging 


Interactive Terminal Interface 
(ITI), 10-7 


interfaces, 5-5 
flexibility in, 2-4 
Interactive Terminal Interface, 
10-7 
for |/O programming, 6-23 to 6-24 
for SORT/MERGE, 9-22 
for symbolic debugger, 7-1 
in VAX-11/750, 4-35 
in VAX-11/780, 4-28 to 4-29 


International Telephone and 
Telegraph Consultative 
Committee (CCITT), 10-7, 10-8 


Internet, 10-5 to 10-7 


interprocess communications, 2-2, 
6-15 to 6-17 


interprocessor communications 
link, 5-6 to 5-7 

interrupts, 4-16 to 4-17, 4-22 
hardware-generated, 6-25 
priority levels for, 4-24 


intertask communications, 10-3 
to 10-4 


interval timers, 4-39 
1/O controller interfaces, 4-28 to 4-29 
I/O devices, realtime, 5-5 to 5-6 


I/O processing, 4-24 to 4-25, 6-23 

to 6-25 

operating system software for, 6-2 
to 6-3 

of RMS files and records, 9-11 to 
9-12 

in VAX-11 FORTRAN, 7-5 

in VAX-11 PL/I, 7-27 


I/O space, 4-24 to 4-25 


I/O system services, 6-6 to 6-14, 6-23 
to 6-24 


ISAM (Indexed Sequential Access 
Method), 7-5 


ISDs (image section descriptors), 8-5 


IT! (Interactive Terminal Interface), 
10-7 


J 


jobs, 6-3, 6-4 
jobs 
structure of, 3-6 to 3-7 
job statistics, 3-9 
journals, 4-4, 8-2, 9-19 
Jump instructions, 4-14 to 4-15 
justifying (of text, in RUNOFF), 8-8 


K 


kernel mode, 4-17 
keypads, 8-2 
keys (in indexed files), 9-10 
keys 

types of matches for, 9-11 
known image, 3-9, 6-4 


L 


LA11 lineprinter, 5-3 


languages, 2-1 

command language, 2-2, 2-4 to 
2-5, 3-1 to 3-4 

common language environment 
for, 7-1 

PDP-11 FORTRAN IV/VAX to 

RSX, 7-33 to 7-34 

MACRO-11, 7-34 

programming, 3-4 to 3-6 

VAX-11 BASIC, 7-13 to 7-20 

VAX-11 BLISS-32, 7-30 to 7-32 

VAX-11C, 7-20 to 7-22 

VAX-11 COBOL, 7-8 to 7-13 

VAX-11 CORAL 66, 7-32 

VAX-11 FORTRAN, 7-2 to 7-8 

VAX-11 MACRO, 7-32 to 7-33 

VAX-11 PASCAL, 7-22 to 7-25 

VAX-11 PL/I, 7-26 to 7-30 


Letterprinter 100, 5-3 

lexical functions, 8-9 

librarian utility, 8-8 to 8-9 
libraries, 8-8 

LIBRARY command, 8-8 to 8-9 
library files, 7-30, 8-4 

limits on resources, 3-9 

line discipline, 10-8 
lineprinter interfaces, 5-5 


lineprinters, 5-2 to 5-3 

LINK command, 8-5 

linker, 6-6, 8-4 to 8-5 
listing-control directives, 7-33 
literal-mode addressing, 4-6 
LOAD command, 7-17 

local event flags, 6-14 
locking of records, 9-13 


lock-management services, 3-7, 
6-14, 6-16 to 6-17 


logicalcommands, 8-9 

logical filenames, 9-3 to 9-4 

logical links, 10-1 

logical names, 3-7, 6-14 
longwords, 4-2 

loops, branch instructions for, 4-14 
LP11lineprinters, 5-2 to 5-3 
LPA11-K, 5-6 


MA780 shared memory 
subsystem, 4-30 to 4-32, 
5-6, 5-7 

MACRO, PDP-11, 6-25 


MACRO, VAX-11 (assembler 
language), 3-4, 7-32 to 7-33 


MACRO-11 (assembler language), 
3-6, 7-34 
macro calls, 7-33 
macro definitions, 7-33 
macro libraries, 8-8 
macros 
in VAX-11 BLISS-32, 7-30 to 7-31 
in VAX-11 MACRO, 7-33 
magnetic tape drives, 5-2 
mailboxes, 3-7, 6-14, 6-17 
Mail facility, 2-2 
main memory subsystems 
in VAX-11/730, 4-38 to 4-39 


in VAX-11/750, 4-34 to 4-35 
in VAX-11/780, 4-28 


maintenance 

for software, 3-10 

see also diagnostics 
manual record locking, 9-13 
mapping, 4-20 to 4-22, 6-17 to 6-18 
mapping registers, 4-17, 4-21 
MAP statement, 7-15 
MASSBUS, 2-2 


in VAX-11/750, 4-35 
in VAX-11/780, 4-28 


MASSBUS adapters, 2-2 
in VAX-11/750, 4-35 
in VAX-11/780, 4-26, 4-28 
in VAX-11/782, 4-32 


mass storage peripherals, 5-1 to 5-2 


MCR (Monitor Console Routine), 
6-25 


MCR command interpreter, 6-26 


MCT (memory controller) module, 
4-38 
memory 
battery backups for, 2-4 
console storage devices for, 5-7 to 
5-8 
linker allocation of, 8-5 
MA780, 4-30 to 4-32 
mass storage peripherals for, 5-1 
to 5-2 
shared, 6-17 
in VAX-11/730 systems, 4-38 to 
4-39 
in VAX-11/750 systems, 4-34 to 
4-35 
in VAX-11/780 systems, 4-28 
virtual, 4-17 


memory caches, see caches 
memory controllers, 2-1, 4-38, 5-6 


memory interconnect, in 
VAX-11/780, 4-27 to 4-28 


memory management, 2-1 to 2-2, 
3-7, 4-19, 6-17 to 6-21 


memory management 
page mapping in, 4-20 to 4-22 
VAX/VMS operating systems 
and, 6-2 


memory management services, 6-20 
MERGE utility, 9-21 to 9-22 


messages 
diagnostics, 7-6 
error, 7-31 
inerrorlog, 3-10 
to mailboxes, 3-7 


modes 
access, 2-2, 2-3 
addressing, 4-1, 4-6 
in EDT editor, 8-2 
processor access, 4-17 to 4-18 
RMS record access, 9-7 to 9-9 
MODIFY statement, 9-14 
Monitor Console Routine (MCR), 
6-25 
Monitor Utility Program 
(MONITOR), 3-9 
multipoint communications, 10-5 
multiprocessing 
environment for, 3-7 
processing concepts for, 4-16 
in VAX-11/782 attached processor 
systems, 4-30 
multiterminal emulators, 10-6 to 10-7 


MUX200/VAX multiterminal 
emulators, 10-6 to 10-7 


N 
NAMELIST statement, 7-5 


names 
directory, 3-8 
file, 8-1 
logical, 3-7, 6-14, 9-3 to 9-4 
native instruction set, 4-1, 4-8 to 4-15 
NCP (Network Control Program), 
10-4 


nesting 
of procedures, 9-16 
in VAX-11 COBOL programs, 
7-8, 7-10 


Network Ancillary Control Process 
(NETACP), 10-4 

Network Application Layer (DNA), 
10-2 

Network Command Terminal 
facility, 2-2, 10-4 

Network Control Program (NCP), 
10-4 

network management, 10-7 to 10-8 

Network Management Layer 
(DNA), 10-2 

networks, 2-2, 10-1 


networks 
DECnet 10-3 to 10-5 
DIGITAL Network Architecture 
for, 10-3 
Internet products for, 10-5 to 10-7 
Packetnet products for, 10-7 to 
10-8 
statistics on activity of, 3-9 


Network Services Layer (DNA), 10-2 
node names, 9-2 
nodes, 10-1, 10-5 


non-processor-request (NPR) 
devices, 5-1 


nontransparent intertask 
communications, 10-4 


normal processes 
priority levels for, 6-21 
scheduling of, 6-22 


NPR (non-processor-request) 
devices, 5-1 


O 


object code, 7-9 

object files, 8-4 

object libraries, 8-8 

octawords, 4-2 

ODS-2 (Files-11 On-Disk Structure 
Level 2), 2-2 

On-Disk Structure Level 2 
(ODS-2), 2-2 

OPEN statement, 7-5 

operating system, 2-1 to 2-2, 6-1 
to 6-26 

operating system 
see also VAX/VMS operating 

system 


operation code (opcode), 4-1 


Operator Communications Manager 


(OPCOM) program, 3-9 
operators (in languages), 7-20 
operators, system, 3-9 to 3-10 


optimization, in VAX-11 
FORTRAN, 7-6 to 7-8 


options files, 8-4 


OTS$ (language-independent 
support), 8-6 


owner processes, 6-3 
owners (records), 9-17 
owners (users), 3-8, 6-4 


p 


packed-decimal data, 4-2 
packed-decimal instructions, 4-11 
Packetnet, 10-7 to 10-8 


Packetnet System Interface 
(PSI), 10-7 
to 10-8 


page faults, 6-19 to 6-20 
Statistics for, 3-9 


page formatting, 8-8 


page mapping, 4-20 to 4-22, 6-17 
to 6-18 


page tables, 4-21 to 4-22, 6-18 
paging, 2-1, 2-4, 6-1, 6-18 to 6-20 


PAL (Programmed Array Logic) 
technology, 4-36 


parallel interfaces, 5-5 
parameters, 3-4, 8-9 


PASCAL, VAX-11, 3-6, 7-22 to 7-25 


passwords, 3-7 
PC (Program Counter), 4-5 to 4-7 


PDP-11 FORTRAN IV/VAX to 
RSX, 3-6, 6-25, 7-33 to 7-34 


PDP-11 instruction set, 4-15, 4-16 
PDP-11 MACRO, 6-25, 
PDP-11 systems, 2-5 


Performance, 2-2 to 2-3 
Statistics on, 3-9 
of VAX-11 BASIC, 7-19 


PERFORM statement, 7-8, 7-9 
peripherals, 2-1, 2-2 


console storage devices, 5-7 to 5-8 


interprocessor communications 
links, 5-6 to 5-7 

mass storage, 5-1 to 5-2 
realtime I/O devices, 5-5 to 5-6 


terminals and interfaces, 5-3 to 5-5 


unit record, 5-2to 5-3 
see also hardware 


Permanent Virtual Circuits 
(PCVs), 10-8 


per-process space, 4-5 


physical address, 4-17, 4-19 
virtual addresses mapped to, 
4-20 to 4-21, 6-17 to 6-18 


Physical Link Layer (DNA), 10-2 
physical links, 10-1 
picture characters, 7-27 


PL/I, VAX-11, 3-5 to 3-6, 7-26 to 7-30 


PLOT statement, 9-14 


point-to-point communications, 10-5 


Polynomial Evaluation (POLY) 


instructions, 2-3 4-11, 4-29, 4-32, 


4-34, 4-40 
position-independent code, 4-7 


Power failures, 2-3 to 2-4 
system recovery after, 3-10 
in VAX-11/782, 4-31 


PPSNs (Public-Packet Switched 
Networks), 10-7 


prefetch instruction buffers, 4-49 
primary keys, 9-10 
printers, 5-2 to 5-3 
print queues, 2-4, 3-10 
PRINT statement, 9-14 
priority dispatching, 4-16 to 4-17 
priority levels 
in CPU, 2-2 
for interrupts, 4-24 


for realtime and normal 
processes, 6-21 


privileged instructions, 4-18 
privileges, 3-8 to 3-9 6-4 
PROBE instructions, 4-18 


Procedures, 4-4 
calling standard for, 7-1 
call and return instructions for, 
4-15 
command, 3-4, 8-9 to 8-10 
nested, 9-16 
system, 8-6 
VAX-11 FORTRAN calls for, 7-6 


Process-Control Block Base 
register, 4-25 


process control services, 6-22 to 
6-23 


Processes, 4-1, 6-3 to 6-4 
communication and control 
between, 6-15 to 6-17 
context of, 4-25 
environment for, 6-5 to 6-15 
scheduling of, 6-21 to 6-23 
structure of, 3-6 to 3-7 


processors, 2-1 
access modes for, 4-17 to 4-18 
architecture of, 4-1 to 4-4 
compatibility mode for, 4-15 
to 4-16 
interprocessor communications 
links for, 5-6 to 5-7 
memory management function 
of, 4-19 


quotas on time on, 3-9 
system programming and, 4-16 to 
4-17 
Processors 

VAX-11/730, 4-36 to 4-37 

VAX-11/750, 4-33 to 4-35 

VAX-11/780, 4-26 to 4-29 

VAX-11/782 attached processor 
systems, 4-30 to 4-32 


Processor Status Longword 
(PSL), 4-17 
instructions for, 4-13 


Processor Status Word, 4-8, 4-17 
in compatibility mode, 4-16 
instructions for, 4-13, 4-14 


process space, 4-5 

process virtual memory, 6-18 
process working set, 6-18 
professional services, 11-2 


Program Counter, 4-5 to 4-7 
instructions for, 4-13 


program development, 3-7, 8-1 to 
8-12 


program developmenttools, 2-2 


Programmable realtime clock, 2-1, 
4-32 

Programmed Array Logic (PAL) 
technology, 4-36 

Programmed interrupt request 
devices, 5-1 

Programmers 
application, 3-1 to 3-6 
system, 3-6 to 3-7 


Programming 


in compatibility mode, 6-25 to 6-26 


environment for, 4-4 to 4-8 


processing concepts for, 4-1 to 4-4 


structured, 7-9, 7-15 
system, 4-16 to 4-25 
in VAX-11 PL/I, 7-30 
in virtual memory, 6-20 


programming interfaces, 6-23 to 
6-24 


programming languages, see 
languages 


program region, 4-5, 6-6 


programs, 6-3 to 6-4 
RMS file operations on, 9-10 to 
9-12 
in VAX-11 BASIC, 7-17 to 7-19 
in VAX-11 BLISS-32, 7-32 
in VAX-11 FORTRAN, 7-6 
in VAX-11 PL/I, 7-26 


program sectioning, 7-33 
program sections, 8-5 
project libraries, 8-11 
protected instructions, 4-18 


protection, 6-4 to 6-5 
access modes for, 2-2 
for files, 6-26 
UIC for, 3-7 to 3-8 


protection codes, 3-8 
protocol emulators, 10-5 to 10-6 


PSI (Packetnet System 
Interface), 10-7 
to 10-8 


PSL, see Processor Status 
Longword 


Public Packet-Switched Networks 
(PPSNs), 10-7 


PVCs (Permanent Virtual 
Circuits), 10-8 


Q 


quadwords, 4-2 
queue entries, 4-4 
queue instructions, 4-13 


Queue I/O Request system 
service, 6-24 to 6-25 


queues 
control over, 3-9 to 3-10 
print, 2-4 


quota, 3-9 


R 


random record access mode, 9-8 
Read operations, 4-38 

READY statement, 9-14 

realtime clocks, 2-1, 4-32 

realtime I/O devices, 5-5 to 5-6 
realtime processes 6-21 to 6-22 
record access streams, 9-12 to 9-13 
record I/O interface, 9-22 


record management services 
(RMS) 2-2, 3-6, 6-23, 7-1 to 
7-2, 9-1 to 9-13 
utilities for, 9-5 
VAX-11C and, 7-21 
VAX-11 PL/I and, 7-28 
Records 
attributes of, 9-9 to 9-10 
RMS access modes for, 9-7 to 9-9 
RMS runtime processing of, 
9-12 to 9-13 
VAX-11 BASIC manipulation of, 
7-16 
VAX-11 COBOL manipulation of, 
7-11 to 7-12 


Record’s File Address (RFA) record 
access mode, 9-8 to 9-9 


record sorts, 9-21 

record transfer modes, 9-13 
recovery, system, 2-3 to 2-4, 3-10 
REFRESH statement, 8-10 
register-deferred mode, 4-6 
register mode, 4-6 


registers 4-1 
control/status and data, 4-24 to 
4-25 


general, 4-5 to 4-8 

mapping, 4-17, 4-21 

PDP-11, in compatibility mode, 
4-15 

Stack Pointer, 4-4 

in VAX-11/730 processor, 4-36 


relative file organization, 9-7 


relative file organization 
access modes to, 9-8 
1/O processing of, 9-11 


reliability, 2-3 to 2-4 


remote diagnostics, 2-4, 3-10, 4-31, 
11-1 


remote file access, 10-4 


Remote Hardware Monitoring 
(RHM), 11-1 


repeat blocks, 7-33 
REPLACE command, 8-11 


Report Writer 
in DATATRIEVE, 9-15 
in VAX-11 COBOL, 7-12 


requests, I/O processing of, 6-24 to 
6-25 


require files, 7-30 
RESERVE command, 8-11 
resource allocation group (LIB$), 8-6 


resources 
accounting statistics for, 3-9 
allocation of, 6-4 
quotas and limits on, 3-9 


resource-sharing networks, 10-1 
response-time histograms, 3-9 
restarts 2-3 

$RESUME system service, 6-16 


Return from Exception or Interrupt 
(REI) instruction, 4-18, 4-24 


Return from Procedure (RET) 
instruction, 4-15 


Return from Subroutine (RSB) 
instruction, 4-15 


REA (Record’s File Address) record 
access mode, 9-8, to 9-9 


RHM (Remote Hardware 
Monitoring), 11-1 


RMS, see record management 
services 


RLO2 disk drive 4-39 
ROLLBACK statement, 7-11 
routing, 10-5 


RSX-11M operating system, 6-25 to 
6-26 


RTL (VAX-11 Common Runtime 
Procedure Library), 7-1, 8-5 to 8-7 


RUN command, 3-4 
RUNOFF, VAX-11, 8-7 to 8-8 


Runtime Procedure Library (RTL), 
7-1, 8-5 to 8-7 


RX01 floppy disk cartridge, 5-7 


S 


scheduler, 6-2 
scheduling, 2-2, 2-4 
scheduling 
event-driven, 3-7 
of processes, 6-21 to 6-23 
schemas, 9-17 to 9-18 
security, see protection 
Selective Cache Invalidation, 4-31 to 
4-32 
SELECT statement, 9-14 
Self-Maintenance Service, 11-2 
sequential file organization, 9-6 to 
9-7 


sequential file organization 
access mode to, 9-7 to 9-8 
I/O processing of, 9-11 


sequential record access mode, 
9-7 to 9-8 

Session Control Layer (DNA), 10-2 

SET command, 8-2 

Set Exception Vector system 
service, 6-15 

SET LIBRARY command, 8-12 

sets, 9-17 to 9-19 

sharable image files, 8-4 

sharable images, 8-4 to 8-6 

sharable programs 


in VAX-11 BASIC, 7-17 
in VAX-11 FORTRAN, 7-6 


shared memory, 6-17 
in VAX-11/782 attached processor 
systems, 4-30 
shared programs, 6-3 
SHOW command 
in Code Management System, 
8-11 to 8-12 
in EDT editor, 8-2 
signaling, in Common Runtime 
Procedure Library, 8-6 


SIMILAR command, 8-11 
SLP editor, 8-3 to 8-4 


software 
DECnet communication, 10-3 to 
10-5 
interrupts requested by, 4-24 
for !/O processing, 6-2 to 6-3 
online maintenance for, 3-10 
support services for, 11-1 to 11-2 


software process-control block, 4-25 


Software Product Services 
(SPS), 11-2 

Software Updates, 11-2 

SORT command in DATATRIEVE, 
9-14 


SORT/MERGE facility, 9-4, 9-21 
to 9-22 


SORT/MERGE facility 
in VAX-11 COBOL, 7-12 


SORT utility, 9-21 
SOS editor, 8-2 to 8-3 


source library 
in VAX-11 COBOL, 7-12 
in VAX-11 FORTRAN, 7-6 


SP, see Stack Pointer 
Special purpose instructions, 4-15 


Spooling 
control over, 2-4 to 2-5 
print, 2-4 


SPS (Software Product 
Services), 11-2 


stack (call) frames, 4-4, 4-8 
Stack Pointer (SP), 4-4, 4-5, 4-7 


Stack Pointer 
in compatibility mode, 4-15 to 4-16 


stacks, 4-4 
Startup files, 8-1 
statements in DATATRIEVE, 9-14 


Statistics, resource accounting and 
performance analysis, 3-9 


storage schemas, 9-18 
STORE statement, 9-14 
structured macro libraries, 7-33 


structured programming 
in VAX-11 BASIC, 7-15 
in VAX-11 COBOL, 7-9 


subdirectories, 9-2 
subject-matter formatting, 8-8 
subprocesses, 6-3 


subprocesses 
system services for, 6-15 to 6-16 


subprograms, 7-10 
subroutines, 4-4 


subroutines 
branch, jump, and return 
instructions for, 4-14 to 4-15 
SORT/MERGE as, 9-22 
VAX-11 FORTRAN calls for, 7-6 


subschemas, 9-18 
supplies, 11-5 
support services, 11-1 to 11-6 


SVCs (Switched Virtual Circuits), 10- 
8 


Swapping, 2-4, 6-22 


Switched Virtual Circuits (SVCs), 10- 
8 


symbolic characters, 7-16 


Symbolic Debugger, VAX-11, 2-4, 
7-1, 8-7 


Symbolic Debugger 
see also debugging 


Symbolic Traceback Facility, 7-1 


Symbolic Traceback Facility 
see also tracebacks 


symbols 
inlinker, 8-4 to 8-5 
in MACRO-11, 7-34 
in VAX-11 MACRO, 7-32 to 7-33 


symbol table files, 8-4 
synchronous interfaces, 5-5 
synchronous line controllers, 5-7 


synchronous record operations, 9-13 


system (users), 3-8, 6-4 
system availability, 2-3 
System Control Block, 4-22 


System Control Block Base 
Register, 4-22 


system events, 6-21 

system images, 8-4 

system management facilities, 2-2 

system managers, 3-7, to 3-9 

system operators, 3-9 to 3-10 

system procedures, 8-6 

system programmers, 3-6 to 3-7 

system programming 
environment for, 4-17 to 4-25 
processing concepts for, 4-16 to 

4-17 

system recovery, 2-3 to 2-4, 3-10 

system region, 4-5, 6-6 

system services, 6-6 to 6-14 


system services 

I/O, 6-23 to 6-24 

lock-management, 6-16 to 6-17 

for memory management, 6-20 to 
6-21 

for process control, 6-15 to 6-16, 
6-22 to 6-23 

VAX-11 C utilization of, 7-21 


system space, 4-5 
system statistics, 3-9 


T 


tag sorts, 9-21 


tape drives, 5-2 
TU58, 4-33, 4-34, 4-37, 5-7 to 5-8 


task-to-task communications, 10-3 
to 10-4 


TE16 tape drive 5-2 


TERMINAL/HOST 
SYNCHRONIZATION, 5-3 


Terminals, 5-3 to 5-5 


terminals 

DECnet communications 
between, 10-4 

Interactive Terminal Interface 
for, 10-7 

keypads on, 8-2 

multiterminal emulators for, 10-6 
to 10-7 


text editors, 8-1 to 8-4 
text libraries, 8-8 


time-of-year clocks, 2-1, 4-32, 4-39 
title formatting, 8-8 


tracebacks, 7-1 
in VAX-11 COBOL, 7-9 
in VAX-11 FORTRAN, 7-8 


trace faults, 4-8 
transaction rollbacks, 9-19 


transparent intertask 
communications, 10-3 to 10-4 


transportability, of VAX-11 
BLISS-32, 7-31 to 7-32 


Transport Layer (DNA), 10-2 


traps, 4-8, 4-22 
asynchronous system, 4-25, 6-15, 
6-16 


TS11 tape drive, 5-2 


TU58 tape-cartridge drives, 4-33, 
4-34, 4-37, 5-7 to 5-8 


TU77 tape drive, 5-2 
TU78 tape drive, 5-2 
type-ahead, 5-3 


U 

UAF (user authorization file), 3-7, 
3-8, 6-4 

UETP (User Environment Test 
Package), 3-11 

UIC see user identification code 


UNIBUS, 2-2 
DR11-B access to, 5-6 
in VAX-11/730, 4-38, 4-39 
in VAX-11/750, 4-35 
in VAX-11/780, 4-29 
UNIBUS adapters, 2-2 


UNIBUS adapters 
in VAX-11/730, 4-39 
in VAX-11/750, 4-35 
in VAX-11/780, 4-26, 4-29 
in VAX-11/782, 4-32 


unit record peripherals, 5-2 to 5-3 
UNIX (operating system), 7-21 
UNRESERVE command, 8-11 
updates, software, 11-2 


user authorization file (UAF), 3-7, 
3-8, 6-4 


User Authorization Program 
(AUTHORIZE), 3-7 


User Environment Test Package 
(UETP), 3-11, 


user identification code (UIC), 3-7 to 
3-9, 6-4, 6-26, 9-1 


user identification code for global 
sections, 6-17 


User Layer (DNA), 10-2 
user mode, 4-17 to 4-18 
users types of, 3-8 

user stacks, 4-4 


V 


variable-length bit field 
instructions, 4-12 to 4-13 


variable-length record format, 9-9 


variable with fixed length control 
record format, 9-10 


VAX-11 2780/3780 protocol 
emulators, 10-5 to 10-6 


VAX-11 3271 protocol emulators, 
10-6 


VAX-11/730 systems 
floating-point accelerator for, 4-40 
main memory subsystem in, 4-38 
to 4-39 
processors for, 4-36 to 4-37 
UNIBUS interface for, 4-39 


VAX-11/750 systems 
physical address spacein, 4-19 
processors for, 4-33 to 4-35 


VAX-11/780 memory 
interconnect, 4-27 to 4-28 


VAX-11/780 systems 
physical address spacein, 4-19 
processors for, 4-26 to 4-29 


VAX-11/782 attached processor 
system, 4-30 to 4-32 


VAX-11 BASIC, 3-5, 7-13 to 7-20 
VAX-11 BLISS-32, 3-6, 7-30 to 7-32 
VAX-11C, 3-5, 7-20 to 7-22 
VAX-11 COBOL, 3-5, 7-8 to 7-13 
VAX-11 COBOL-74, 7-12 to 7-13 


VAX-11 Code Management System 
(DEC/CMS), 8-11 to 8-12 


VAX-11 Common Data Dictionary 
(CDD), 7-8, 9-5, 9-6, 9-14, 
9-16 to 9-18 


VAX-11 Common Runtime Procedure 
Library (RTL), 7-1, 8-5 to 8-7 


VAX-11 CORAL 66, 3-6, 7-32 


VAX-11 DATATRIEVE, 2-4, 9-5, 
9-6, 9-13 to 9-16 


VAX-11 DBMS, see Database 
Management System 


VAX-11 FMS, 2-4, 9-6, 9-19 to 9-21 
VAX-11 FORTRAN, 3-5, 7-2 to 7-8 


VAX-11 MACRO (assembler 
language), 3-4, 7-32 to 7-33 


VAX-11 PASCAL, 3-6, 7-22 to 7-25 
VAX-11 PL/I, 3-5 to 3-6, 7-26 to 7-30 


VAX-11 PSI (Packetnet System 
Interface), 10-7 to 10-8 


VAX-11 Record Management 
Services, see record management 
services 


VAX-11 RUNOFF, 8-7 to 8-8 


VAX-11 SORT/MERGE utility, 9-21 
to 9-22 


VAX-11 Symbolic Debugger, 2-4, 
7-1, 8-7 
VAX courses, 11-3 to 11-4 


VAX/VMS command language 
(DIGITAL command language), 
2-2, 2-4 to 2-5, 3-1 to 3-4 

VAX/VMS command language 
procedures in, 8-9 to 8-10 

VAX/VMS operating system, 2-1 
to 2-2, 6-1 to 6-26 

VAX/VMS operating system 


languages supported by, 3-4 to 3-5 


reliability features of, 2-3 to 2-4 


vectors, exception and interrupt, 
4-22 


VERIFY command, 8-12 
VERIFY utility, 9-5 
video terminals, 5-5 


virtual addresses, 4-1, 6-17 to 6-18 
physical addresses mapped 
from, 4-20 to 4-22 
structure of, 4-4 to 4-5 


virtual addressing, 4-17 
virtual address space, 4-19 


virtual address space 
allocation of, 6-5 to 6-6 


virtual circuits, 10-8 


vitual memory, 2-1 to 2-2, 4-17 
process, 6-18 
programming in, 6-20 


VT100 video terminals, 5-5 


VT100 video terminals 
keypads on, 8-2 


W 


warnings in VAX-11 PASCAL, 7-25 
warranties, 11-1 to 11-2 


WCS (writable control store), 4-26, 
4-30, 4-33 


window editing, 8-1 
words, 4-2 

working set, 6-18 
world (users), 3-8, 6-4 


Writable Control Store (WCS), 4-26, 
4-30, 4-33 


Write operations, 4-38 


X 
X,25, 10-7, 10-8 


BLANK 


BLANK 
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